Subject: [TLS] DISCUSS on Server Name Indication of 4366-bis

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 17 Aug 2010 10:58:35 -0700

Alexey and Peter logged some DISCUSS comments on section 3 of
draft-ietf-tls-rfc4366-bis-10 during IESG review.  Below are the
comments and the proposed resolutions.  Please review and send comments
to the list. 

Thanks,

Joe

1) From Peter
" The "HostName" type seems to be underspecified. Is this limited to a
"traditional domain name", i.e., a fully qualified domain name all of
whose
labels are "LDH labels" (as defined in RFC 5890)? Or can the HostName
type be an
"internationalized domain name", i.e., a DNS domain name at least one of
whose
labels is a "U-label" or "A-label" (as defined in RFC 5890)? As far as I
can
see, the description "represented as a byte string using ASCII encoding
without
a trailing dot" does not exclude IDNs containing A-labels. If the intent
is to
support IDNs, then it would be good to note that fact, because otherwise
eliminating the UTF-8 representation of the HostName type might be
considered a
step backward (unless there are plans to define a new i18nHostName
type)."

Proposed resolution: add the following to the end of the paragraph along
with a normative reference to RFC 5890:
 
"This allows the support of internationalized domain names through the
use of A-labels defined in [RFC 5890]."

2) From Alexey

"3. Server Name Indication

      struct {
          NameType name_type;
          select (name_type) {
              case host_name: HostName;
          } name;
      } ServerName;

      enum {
          host_name(0), (255)
      } NameType;

      opaque HostName<1..2^16-1>;

      struct {
          ServerName server_name_list<1..2^16-1>
      } ServerNameList;

 [...]

   However, for backward compatibility, all future NameTypes
   MUST begin with a 16-bit length field.

Can you please clarify what this means?
I am looking at both ServerName and
NameType definitions and I don't see what you are talking about."

Proposed resolution: replace  " However, for backward compatibility, all
future NameTypes MUST begin with a 16-bit length field." With:

"The data structure associated with the host_name NameType is a
variable-length vector that begins with a 16-bit length. For backward
compatibility, all future data structures associated with new NameTypes
MUST begin with a 16-bit length field."

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 17 Aug 2010 11:05:06 -0700

> MUST begin with a 16-bit length field."

This is actually for "forward compatibility" so that new name types
can be skipped by old software that doesn't know about them.

Mike