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