Security Considerations: bad split

Harald Tveit Alvestrand harald at alvestrand.no
Sun Dec 7 09:03:47 CET 2008


Having re-read the security considerations on -bidi, I fail to see how 
it's possible to comprehend these few paragraphs without just having 
read -bidi.

I also fail to see how these few paragraphs will enhance people's 
understanding of any of the other documents.

For reference, the text is:

9.  Security Considerations

   This modification will allow some strings to be used in Stringprep
   contexts that are not allowed today.  It is possible that differences
   in the interpretation of the specification between old and new
   implementations could pose a security risk, but it is difficult to
   envision any specific instantiation of this.

   Any rational attempt to compute, for instance, a hash over an
   identifier processed by Stringprep would use network order for its
   computation, and thus be unaffected by the changes proposed here.

  While it is not believed to pose a problem, if display routines had
   been written with specific knowledge of the RFC 3454 Stringprep
   prohibitions, it is possible that the potential problems noted under
   "backwards compatibility" could cause new kinds of confusion.


In the case of -bidi, I see the drive for an unified security 
considerations section as quixotic, harmful and nonsensical.

Clear enough opinion?

                    Harald



More information about the Idna-update mailing list