draft-ietf-tls-extensions-06.txt

[Steve Bellovin <smb@research.att.com>]

During Authors' 48 Hours, the following change was proposed to 
draft-ietf-tls-extensions-06.txt.  I'm not completely comfortable with 
this; I'd like advice from people who understand IDNA issues better 
than I do.  Does this change rule out CJK certificates in TLS?  If so, 
does anyone have any better changes to suggest?

  Section 6.1
  -----------
  
  OLD:
  
  Implementations MUST ensure that a buffer overflow does not occur
  whatever the values of the length fields in server_name.
  
  NEW: (addition of new paragraph right after previous paragraph)
  
  Implementations MUST ensure that a buffer overflow does not occur
  whatever the values of the length fields in server_name.
  
  Although this document specifies an encoding for internationalized
  hostnames in the server_name extension, it does not address any
  security issues associated with the use of internationalized hostnames
  in TLS - in particular, the consequences of "spoofed" names that are
  indistinguishable from another name when displayed or printed. Server
  certificates SHOULD NOT be provided for internationalized hostnames
  unless procedures are adopted to mitigate the risk of "spoofed"
  names.

While we're at it, the following change was suggested; it seems quite 
reasonable to me.

Section 3.1

OLD:

"HostName" contains the fully qualified DNS hostname of the server,
as understood by the client. The hostname is represented as a
byte string using UTF-8 encoding [UTF8], without a trailing dot.
(Note that the use of UTF-8 here is for storage of the name as used
in the DNS protocol. This imply that hostnames encoded according to
IDNA [IDNA] is in ascii only, and therefore is to be compared as
ascii DNS names.)

NEW: (addition of new paragraph right after the previous paragraph:

"HostName" contains the fully qualified DNS hostname of the server,
as understood by the client. The hostname is represented as a
byte string using UTF-8 encoding [UTF8], without a trailing dot.
(Note that the use of UTF-8 here is for storage of the name as used
in the DNS protocol. This imply that hostnames encoded according to
IDNA [IDNA] is in ascii only, and therefore is to be compared as
ascii DNS names.)

If the hostname labels contain only US-ASCII characters, then the
client MUST ensure that labels are separated only by the byte 0x2E,
representing the dot character U+002E (requirement 1 in section 3.1 of
[IDNA] notwithstanding).

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)