Security considerations breakdown (was: Re: Security considerations breakdown and names of the specs (was: Re: Security Considerations: bad split))

Harald Alvestrand harald at alvestrand.no
Wed Dec 10 15:35:41 CET 2008


> Harald (not to pick on him) also wrote "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." Take a look at 
> it below; I just don't understand this. The first paragraph is 
> general, and applies equally well to *all* the documents, and is not 
> specific to bidi. Even in the second paragraph, there is nothing in it 
> that requires an any depth of understanding of bidi: the only thing it 
> requires is a knowledge that in-memory character order is different 
> than visually-displayed order. That could be explained in a single 
> lead-in sentence.

Despite not being picked on, I choose to pick back.

Again, we are discussing this text:

   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 <http://tools.ietf.org/html/rfc3454> Stringprep
   prohibitions, it is possible that the potential problems noted under
   "backwards compatibility" could cause new kinds of confusion.



The first paragraph contains the word "this". In this particular 
instance, "this" points to the document in which it is contained.

For some of the strings allowed (the ZWNJ in particular), it is 
extremely easy to envision how the difference in implementation could 
pose a security risk, so the statement is false for the whole IDNABIS 
suite. It is, however, true for -bidi.

There are no other places in IDNABIS where the difference between 
display order and network order matters, so the second paragraph is 
meaningless in any other context than -bidi.

I think we agree that the third paragraph is -bidi specific.

I stand by my judgment: All three paragraphs are -bidi specific, and are 
best kept in -bidi.

                     Harald





More information about the Idna-update mailing list