As far as the security sections go, I don't think people have really looked at the existing text; it has significant problems. I reproduced the sections below; they are not long.<br>
<br>
<div style="margin-left: 40px;"><aside>As an aside, I somewhat resent the innuendo in the statement on this thread: "I would personally infer that anyone
advocating such a battle is simply trying to <span class="nfakPe">delay</span> the WG's work, but that would be just my opinion".<br>
<br>
The documents are
still quite difficult to read and understand. While we are behind our
schedule, in my opinion that is more due to the difficulty
in getting even fairly simple changes made in the documents, such as
getting qualifications on categorical statements that state opinions
("are dangerous", "are recognized as") but without any facts to back them up, nor even single
examples to illustrate purported problems.<br>
<br>
While I can understand the authors' being frustrated at the schedule,
trying to be a conscientious reviewer of these documents is also rather
painful, also periodically requiring a large expenditure of time. Most
of us (both authors and other participants) have day jobs, and trying to
squeeze in time for careful review and discussion is often difficult.
So all of us need to have some consideration of what constraints others
have.<br>
<br>
I believe that the structure of IDNA2008 is workable, but it represents
a pretty major change in an existing, widely-deployed specification
(IDNA2003). It is much more complicated than the original, and
represents an opportunity for serious interoperability and security
problems if not implemented correctly. (I've been accused of being too
negative on the security angle, but in my experiences, it pays to look
at the worst-case scenarios because they so, so often materialize.)<br><br>I
think it is possible to deal with these problems, but we have to make
it really clear to people what the issues are.<br></aside><br>
</div>
<br>
Harald remarked that "I fully expect the overall registry designer to look at -bidi for 2
seconds, then throw it in the direction of the string-processing expert
and say 'implement this'. I expect him to pay much more careful
attention to -rationale." What this statement points out is that it *would* make sense to have two different sections in the security
considerations: one targeted at "Registration", and one targeted at
"Domain Name Lookup": those are the two classes of users we distinguish in Protocol, classes with very
different understanding of the issues. Right now from the existing text there, I doubt that a registry person would really understand the important considerations: what they should do to avoid security problems, such as how to handle eszett or ZWJ. But that is an existing problem, not an issue with whether or not the text is in one place.<br>
<br>
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 <b>all</b>
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.<br>
<br>
Look at the security section for Defs below. Again, there is nothing particular to Defs in that section. This text could go anywhere. <br><br>Tables already has a pure redirection. <br><br>Rationale has a first paragraph where it says "consequently introduces
no new security issues" and points to Defs, but *not* to Protocol, where
a significant part of the security considerations are. (And there is no pointer from Defs to Protocol.) It then has a
following section where (despite the first paragraph's claim of no security issues") it discusses some absolutely crucial issues,
which are the security considerations introduced by the fact that
IDNA2008 is substantially different than IDNA2003.<br>
<br>
To coalesce these into a Protocol is not a massive rework; we are only are talking about a couple of pages of text here; to get it into a comprehensible whole would not take long.<br>
<br>
And if these were in one place it would make it far easier to see
whether or not they cover all the issues. And they miss major ones: the
problems introduced by eszett, sigma, and joiners, on the one hand, and
the indeterminacies allowed by local mappings on the other. Cf <span><a title="http://docs.google.com/Doc?id=dfqr8rd5_361dwv9cff8" href="http://docs.google.com/Doc?id=dfqr8rd5_361dwv9cff8" id="dwie">http://docs.google.com/Doc?id=dfqr8rd5_361dwv9cff8</a> .</span><br>
<br>
<b>Let me sum it up.</b><br>
<ul><li>The Security Considerations for IDNA2003 are arbitrarily divided
between the documents, with subject matter that is not particularly
associated with the material in the document in which they occur.<br>
</li><li>The best situation would be to merge them into a single body of
text in Protocol, and just point to it. This is precisely following the model
already used in Tables -- this is not some radical, wild-eyed
innovation.</li><li>Ideally, that body of text should be broken into two sections that mirror the two main audiences, since each will have substantially different backgrounds and understanding. (This is a change that would require some thought and effort, but the fact that it is missing is orthogonal to a coalescing.)<br>
</li><li>Such a merger of text would also let us see more clearly what is redundant and missing.<br>
</li><li>If we really don't want a comprehensive discussion,
then the least we should do is add a note in each Security
Considerations section that explains the situation, something like:</li><ul><li>"Note: The security implications of IDNA2008 are split into
sections in the different documents comprising IDNA2008. Understanding
the overall security implications requires review of each of those
sections. Due to time constraints, the split of material between the documents is arbitrary, and
not necessarily associated with the subject of that document."</li><li>(Ok, I'm not really serious about that last sentence.)</li></ul></ul>
Mark<br>
<hr size="2" width="100%"><br>
<br><h1>
Tables</h1>
<pre class="newpage"><span class="h2"><h2><a name="section-6">6</a>. Security Considerations</h2></span><br><br> The security issues associated with this work are discussed in<br> [<a href="http://tools.ietf.org/html/draft-ietf-idnabis-tables-04#ref-IDNA2008-rationale" title=""Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale"">IDNA2008-rationale</a>] and [<a href="http://tools.ietf.org/html/draft-ietf-idnabis-tables-04#ref-IDNA2008-protocol" title=""Internationalizing Domain Names in Applications (IDNA): Protocol"">IDNA2008-protocol</a>].<br>
<br><br></pre><h1>Bidi</h1><pre class="newpage"><span class="h2"><h2><a name="section-9">9</a>. Security Considerations</h2></span><br><br> This modification will allow some strings to be used in Stringprep<br> contexts that are not allowed today. It is possible that differences<br>
in the interpretation of the specification between old and new<br> implementations could pose a security risk, but it is difficult to<br> envision any specific instantiation of this.<br><br> Any rational attempt to compute, for instance, a hash over an<br>
identifier processed by Stringprep would use network order for its<br> computation, and thus be unaffected by the changes proposed here.<br> While it is not believed to pose a problem, if display routines had<br> been written with specific knowledge of the <a href="http://tools.ietf.org/html/rfc3454">RFC 3454</a> Stringprep<br>
prohibitions, it is possible that the potential problems noted under<br> "backwards compatibility" could cause new kinds of confusion.<br><br></pre><h1>Defs</h1><pre class="newpage"><br><span class="h2"><h2>
<a name="section-4">4</a>. Security Considerations</h2></span><br><br> Security on the Internet partly relies on the DNS. Thus, any change<br> to the characteristics of the DNS can change the security of much of<br>
the Internet.<br><br> Domain names are used by users to identify and connect to Internet<br> servers. The security of the Internet is compromised if a user<br> entering a single internationalized name is connected to different<br>
servers based on different interpretations of the internationalized<br> domain name.<br><br> When systems use local character sets other than ASCII and Unicode,<br> these specifications leave the problem of converting between the<br>
local character set and Unicode up to the application or local<br> system. If different applications (or different versions of one<br> application) implement different transcoding rules, they could<br> interpret the same name differently and contact different servers.<br>
This problem is not solved by security protocols, such as TLS, that<br> do not take local character sets into account.<br><br> To help prevent confusion between characters that are visually<br> similar, it is suggested that implementations provide visual<br>
indications where a domain name contains multiple scripts. Such<br> mechanisms can also be used to show when a name contains a mixture of<br> simplified and traditional Chinese characters, or to distinguish zero<br>
and one from O and l. DNS zone administrators may impose<br> restrictions (subject to the limitations identified elsewhere in<br> these documents) that try to minimize characters that have similar<br> appearance or similar interpretations. It is worth noting that there<br>
are no comprehensive technical solutions to the problems of<br> confusable characters. One can reduce the extent of the problems in<br> various ways, but probably never eliminate it. Some specific<br> suggestions about identification and handling of confusable<br>
characters appear in a Unicode Consortium publication<br> [<a href="http://tools.ietf.org/html/draft-ietf-idnabis-defs-04#ref-Unicode-UTR36" title=""Unicode Technical Report #36: Unicode Security Considerations"">Unicode-UTR36</a>].<br>
<br> No mechanism involving names or identifiers alone can protect against<br> a wide variety of security threats and attacks that are largely<br> independent of the naming or identification system. These attacks<br>
include spoofed pages, DNS query trapping and diversion, and so on.<br><br><br></pre><h1>Protocol</h1><pre class="newpage"><span class="h2"><h2><a name="section-7">7</a>. Security Considerations</h2></span><br><br> The general security principles and issues for IDNA appear in<br>
[<a href="http://tools.ietf.org/html/draft-ietf-idnabis-protocol-08#ref-IDNA2008-Defs" title=""Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework"">IDNA2008-Defs</a>] with additional explanation in [<a href="http://tools.ietf.org/html/draft-ietf-idnabis-protocol-08#ref-IDNA2008-Rationale" title=""Internationalizing Domain Names for Applications (IDNA): Issues, Explanation, and Rationale"">IDNA2008-Rationale</a>].<br>
The comments below are specific to the registration and loopup<br> protocols specified in this document, but should be read in the<br> context of the material in the first of those documents and the<br> definitions and specifications, identified there, on which this one<br>
depends.<br><br> This memo describes procedures for registering and looking up labels<br> that are not compatible with the preferred syntax described in the<br> base DNS specifications (STD13 [<a href="http://tools.ietf.org/html/rfc1034" title=""Domain names - concepts and facilities"">RFC1034</a>] [<a href="http://tools.ietf.org/html/rfc1035" title=""Domain names - implementation and specification"">RFC1035</a>] and Host<br>
Requirements [<a href="http://tools.ietf.org/html/rfc1123" title=""Requirements for Internet Hosts - Application and Support"">RFC1123</a>]) because they contain non-ASCII characters.<br> These procedures depend on the use of a special ASCII-compatible<br>
encoding form that contains only characters permitted in host names<br> by those earlier specifications. The encoding used is Punycode<br> [<a href="http://tools.ietf.org/html/rfc3492" title=""Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)"">RFC3492</a>]. No security issues such as string length increases or new<br>
allowed values are introduced by the encoding process or the use of<br> these encoded values, apart from those introduced by the ACE encoding<br> itself.<br><br> Domain names (or portions of them) are sometimes compared against a<br>
set of domains to be given special treatment if a match occurs, e.g.,<br> treated as more privileged than others or blocked in some way. In<br> such situations, it is especially important that the comparisons be<br>
done properly, as specified in Requirement 2 of <a href="http://tools.ietf.org/html/draft-ietf-idnabis-protocol-08#section-3.1">Section 3.1</a>. For<br> labels already in ASCII form (i.e., are LDH-labels or A-labels), the<br>
proper comparison reduces to the same case-insensitive ASCII<br> comparison that has always been used for ASCII labels.<br><br> The introduction of IDNA means that any existing labels that start<br> with the ACE prefix would be construed as A-labels, at least until<br>
they failed one of the relevant tests, whether or not that was the<br> intent of the zone administrator or registrant. There is no evidence<br> that this has caused any practical problems since <a href="http://tools.ietf.org/html/rfc3490">RFC 3490</a> was<br>
adopted, but the risk still exists in principle.<br><br><br></pre><h1>
Rationale</h1><div><div>
<pre class="newpage"><span class="h2"><h2><a name="section-12">12</a>. Security Considerations</h2></span><br><span class="h3"><h3><a name="section-12.1">12.1</a>. General Security Issues with IDNA</h3></span><br><br> This document in the IDNA2008 series is purely explanatory and<br>
informational and consequently introduces no new security issues. It<br> would, of course, be a poor idea for someone to try to implement from<br> it; such an attempt would almost certainly lead to interoperability<br>
problems and might lead to security ones. A discussion of security<br> issues with IDNA2008, and IDNA generally, appears in [<a href="http://tools.ietf.org/html/draft-ietf-idnabis-rationale-05#ref-IDNA2008-Defs" title=""Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework"">IDNA2008-Defs</a>].<br>
<br><span class="h3"><h3><a name="section-12.2">12.2</a>. Security Differences from IDNA2003</h3></span><br><br> The registration and lookup models described in this set of documents<br> change the mechanisms available for lookup applications to determine<br>
the validity of labels they encounter. In some respects, the ability<br> to test is strengthened. For example, putative labels that contain<br> unassigned code points will now be rejected, while IDNA2003 permitted<br>
them (something that is now recognized as a considerable source of<br> risk). On the other hand, the protocol specification no longer<br> assumes that the application that looks up a name will be able to<br> determine, and apply, information about the protocol version used in<br>
registration. In theory, that may increase risk since the<br> application will be able to do less pre-lookup validation. In<br> practice, the protection afforded by that test has been largely<br> illusory for reasons explained in <a href="http://tools.ietf.org/html/rfc4690">RFC 4690</a> and above.<br>
<br> Any change to Stringprep or, more broadly, the IETF's model of the<br> use of internationalized character strings in different protocols,<br> creates some risk of inadvertent changes to those protocols,<br>
invalidating deployed applications or databases, and so on. The same<br> considerations that would require changing the IDN prefix (see the<br> discussion of prefix changes in <a href="http://tools.ietf.org/html/draft-ietf-idnabis-rationale-05#section-7.4">Section 7.4</a>) are the ones that would,<br>
e.g., invalidate certificates or hashes that depend on Stringprep,<br> but those cases require careful consideration and evaluation. More<br> important, it is not necessary to change Stringprep at all in order<br>
to create a definition or implementation of IDNA as specified in this<br> set of documents. Because these documents do not depend on<br> Stringprep at all, the question of upgrading other protocols that do<br> depend on Stringprep can be left to experts on those protocols: there<br>
is no dependency between IDNA changes and possible upgrades to<br> security protocols or conventions.<br></pre>
<br>
</div><br></div><br>