Security considerations breakdown (was: Re: Security considerations breakdown and names of the specs (was: Re: Security Considerations: bad split))
Mark Davis
mark at macchiato.com
Wed Dec 10 02:43:17 CET 2008
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.
<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 delay the WG's work, but that would be just my opinion".
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.
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.
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.)
I think it is possible to deal with these problems, but we have to make it
really clear to people what the issues are.
</aside>
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.
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.
Look at the security section for Defs below. Again, there is nothing
particular to Defs in that section. This text could go anywhere.
Tables already has a pure redirection.
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.
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.
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
http://docs.google.com/Doc?id=dfqr8rd5_361dwv9cff8 .
*Let me sum it up.*
- 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.
- 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.
- 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.)
- Such a merger of text would also let us see more clearly what is
redundant and missing.
- 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:
- "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."
- (Ok, I'm not really serious about that last sentence.)
Mark
------------------------------
Tables
6. Security Considerations
The security issues associated with this work are discussed in
[IDNA2008-rationale
<http://tools.ietf.org/html/draft-ietf-idnabis-tables-04#ref-IDNA2008-rationale>]
and [IDNA2008-protocol
<http://tools.ietf.org/html/draft-ietf-idnabis-tables-04#ref-IDNA2008-protocol>].
Bidi
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
<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.
Defs
4. Security Considerations
Security on the Internet partly relies on the DNS. Thus, any change
to the characteristics of the DNS can change the security of much of
the Internet.
Domain names are used by users to identify and connect to Internet
servers. The security of the Internet is compromised if a user
entering a single internationalized name is connected to different
servers based on different interpretations of the internationalized
domain name.
When systems use local character sets other than ASCII and Unicode,
these specifications leave the problem of converting between the
local character set and Unicode up to the application or local
system. If different applications (or different versions of one
application) implement different transcoding rules, they could
interpret the same name differently and contact different servers.
This problem is not solved by security protocols, such as TLS, that
do not take local character sets into account.
To help prevent confusion between characters that are visually
similar, it is suggested that implementations provide visual
indications where a domain name contains multiple scripts. Such
mechanisms can also be used to show when a name contains a mixture of
simplified and traditional Chinese characters, or to distinguish zero
and one from O and l. DNS zone administrators may impose
restrictions (subject to the limitations identified elsewhere in
these documents) that try to minimize characters that have similar
appearance or similar interpretations. It is worth noting that there
are no comprehensive technical solutions to the problems of
confusable characters. One can reduce the extent of the problems in
various ways, but probably never eliminate it. Some specific
suggestions about identification and handling of confusable
characters appear in a Unicode Consortium publication
[Unicode-UTR36
<http://tools.ietf.org/html/draft-ietf-idnabis-defs-04#ref-Unicode-UTR36>].
No mechanism involving names or identifiers alone can protect against
a wide variety of security threats and attacks that are largely
independent of the naming or identification system. These attacks
include spoofed pages, DNS query trapping and diversion, and so on.
Protocol
7. Security Considerations
The general security principles and issues for IDNA appear in
[IDNA2008-Defs
<http://tools.ietf.org/html/draft-ietf-idnabis-protocol-08#ref-IDNA2008-Defs>]
with additional explanation in [IDNA2008-Rationale
<http://tools.ietf.org/html/draft-ietf-idnabis-protocol-08#ref-IDNA2008-Rationale>].
The comments below are specific to the registration and loopup
protocols specified in this document, but should be read in the
context of the material in the first of those documents and the
definitions and specifications, identified there, on which this one
depends.
This memo describes procedures for registering and looking up labels
that are not compatible with the preferred syntax described in the
base DNS specifications (STD13 [RFC1034
<http://tools.ietf.org/html/rfc1034>] [RFC1035
<http://tools.ietf.org/html/rfc1035>] and Host
Requirements [RFC1123 <http://tools.ietf.org/html/rfc1123>])
because they contain non-ASCII characters.
These procedures depend on the use of a special ASCII-compatible
encoding form that contains only characters permitted in host names
by those earlier specifications. The encoding used is Punycode
[RFC3492 <http://tools.ietf.org/html/rfc3492>]. No security issues
such as string length increases or new
allowed values are introduced by the encoding process or the use of
these encoded values, apart from those introduced by the ACE encoding
itself.
Domain names (or portions of them) are sometimes compared against a
set of domains to be given special treatment if a match occurs, e.g.,
treated as more privileged than others or blocked in some way. In
such situations, it is especially important that the comparisons be
done properly, as specified in Requirement 2 of Section 3.1
<http://tools.ietf.org/html/draft-ietf-idnabis-protocol-08#section-3.1>.
For
labels already in ASCII form (i.e., are LDH-labels or A-labels), the
proper comparison reduces to the same case-insensitive ASCII
comparison that has always been used for ASCII labels.
The introduction of IDNA means that any existing labels that start
with the ACE prefix would be construed as A-labels, at least until
they failed one of the relevant tests, whether or not that was the
intent of the zone administrator or registrant. There is no evidence
that this has caused any practical problems since RFC 3490
<http://tools.ietf.org/html/rfc3490> was
adopted, but the risk still exists in principle.
Rationale
12. Security Considerations
12.1. General Security Issues with IDNA
This document in the IDNA2008 series is purely explanatory and
informational and consequently introduces no new security issues. It
would, of course, be a poor idea for someone to try to implement from
it; such an attempt would almost certainly lead to interoperability
problems and might lead to security ones. A discussion of security
issues with IDNA2008, and IDNA generally, appears in [IDNA2008-Defs
<http://tools.ietf.org/html/draft-ietf-idnabis-rationale-05#ref-IDNA2008-Defs>].
12.2. Security Differences from IDNA2003
The registration and lookup models described in this set of documents
change the mechanisms available for lookup applications to determine
the validity of labels they encounter. In some respects, the ability
to test is strengthened. For example, putative labels that contain
unassigned code points will now be rejected, while IDNA2003 permitted
them (something that is now recognized as a considerable source of
risk). On the other hand, the protocol specification no longer
assumes that the application that looks up a name will be able to
determine, and apply, information about the protocol version used in
registration. In theory, that may increase risk since the
application will be able to do less pre-lookup validation. In
practice, the protection afforded by that test has been largely
illusory for reasons explained in RFC 4690
<http://tools.ietf.org/html/rfc4690> and above.
Any change to Stringprep or, more broadly, the IETF's model of the
use of internationalized character strings in different protocols,
creates some risk of inadvertent changes to those protocols,
invalidating deployed applications or databases, and so on. The same
considerations that would require changing the IDN prefix (see the
discussion of prefix changes in Section 7.4
<http://tools.ietf.org/html/draft-ietf-idnabis-rationale-05#section-7.4>)
are the ones that would,
e.g., invalidate certificates or hashes that depend on Stringprep,
but those cases require careful consideration and evaluation. More
important, it is not necessary to change Stringprep at all in order
to create a definition or implementation of IDNA as specified in this
set of documents. Because these documents do not depend on
Stringprep at all, the question of upgrading other protocols that do
depend on Stringprep can be left to experts on those protocols: there
is no dependency between IDNA changes and possible upgrades to
security protocols or conventions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20081209/01189acc/attachment-0001.htm
More information about the Idna-update
mailing list