Subject: [TLS] 4366bis TLSext SNI -- case-sensitivity, permitted chars

From: Martin Rex <[email-masked]>
Date: Thu, 18 Nov 2010 20:15:46 +0100 (MET)

Looking at the OpenSSL diffs for CVE-2010-3864 and crosschecking with
rfc4366 and rfc4366bis I noticed that some text was removed or lost
from the description of the Server Name Indication extension
for rfc4366->rfc4366bis.

The IMHO most important part that was lost is:

    "MUST compare ... case-insensitively."

and OpenSSL appears to perform a case-sensitive match (strncmp) only.

A fairly superficial "grep" TLS Email archives didn't highlight any
discussion that led to the dismissal of that text, but I might well
be overlooking messages.

Original Text text is:
https://tools.ietf.org/html/rfc4366#page-10

   "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.

   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).  If the server needs to match the
   HostName against names that contain non-US-ASCII characters, it MUST
   perform the conversion operation described in Section 4 of [IDNA],
   treating the HostName as a "query string" (i.e., the AllowUnassigned
   flag MUST be set).  Note that IDNA allows labels to be separated by
   any of the Unicode characters U+002E, U+3002, U+FF0E, and U+FF61;
   therefore, servers MUST accept any of these characters as a label
   separator.  If the server only needs to match the HostName against
   names containing exclusively ASCII characters, it MUST compare ASCII
   names case-insensitively.

   Literal IPv4 and IPv6 addresses are not permitted in "HostName".

New text is:
https://tools.ietf.org/html/draft-ietf-tls-rfc4366-bis-12#page-8

  "HostName" contains the fully qualified DNS hostname of the server,
   as understood by the client. The hostname is represented as a byte
   string using ASCII encoding without a trailing dot. This allows the
   support of internationalized domain names through the use of A-labels
   defined in [RFC5890].

   Literal IPv4 and IPv6 addresses are not permitted in "HostName".

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 18 Nov 2010 20:38:45 +0100 (MET)

> and OpenSSL appears to perform a case-sensitive match (strncmp) only.

To avoid confusions--the comparison that I'm talking about is the
one required by this check (now explicitly spelled out in rfc4366bis):

                                                                      A
   server that implements this extension MUST NOT accept the request to
   resume the session if the server_name extension contains a different
   name. Instead, it proceeds with a full handshake to establish a new
   session. When resuming a session, the server MUST NOT include a
   server_name extension in the server hello.

Case-insensitivity also affects any other comparisons involving the
SNI hostname value, e.g. related to selecting a server credential, 

-Martin

---

From: Geoffrey Keating <[email-masked]>
Date: 18 Nov 2010 11:52:51 -0800

> and OpenSSL appears to perform a case-sensitive match (strncmp) only.
...
>    Literal IPv4 and IPv6 addresses are not permitted in "HostName".

Perhaps we could insert this between the two paragraphs quoted:

  The DNS hostname is to be compared in a case-insensitive manner but
  case should be preserved, as described in [RFC1035].

(The RFC 1035 reference is so that we don't have to explain what
'case-insensitive' means.)

---

From: Martin Rex <[email-masked]>
Date: Thu, 18 Nov 2010 21:14:17 +0100 (MET)

> SNI hostname value, e.g. related to selecting a server credential, 

and btw. the part "... it proceeds with a full handshake to establish
a new session" appears to not have been implemented in OpenSSL yet.
OpenSSL ignores the SNI extension value and resumes anyway, in spite
of the mismatch.  I can not currently think of a security issue,
but it causes misleading results for "black-box interop tests".

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 18 Nov 2010 21:37:51 +0100 (MET)

> 'case-insensitive' means.)
 
Considering the new Reference to [RFC5890], pointing to Section 2.3.2.4
of that document might be more appropriate.

https://tools.ietf.org/html/rfc5890#section-2.3.2.4

So something like

   DNS hostnames are case-insensitive.  The algorithm to compare
   hostnames is described in [RFC5890] Section 2.3.2.4.

might be more consistent.

-Martin