Transport Layer Security (TLS) Extensions: Extension Definitions
draft-ietf-tls-rfc4366-bis-12

[Ballot comment]
I have the following comments:


3. Server Name Indication

  Currently, the only server names supported are DNS hostnames;
  however, this does not imply any dependency of TLS on DNS, and other
  name types may be added in the future (by an RFC that updates this
  document).  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 TLS MAY treat

I think by mistake you removed the dot after "field".

  provided server names as opaque data and pass the names and types to
  the application.

10.1 pkipath MIME Type Registration

The "Encoding Considerations" section should say that the data is binary.

[Ballot comment]
Cleared, with the understand that my former DISCUSS will addressed by adding the following sentence to the end of the paragraph on the "HostName" type, as proposed by Joe Salowey:

  This allows the support of internationalized domain names through the
  use of A-labels as defined in [RFC 5890].

[Ballot discuss]
This is a DISCUSS-DISCUSS that I expect to clear during of after the telechat. This document obsoletes RFC 4366 (if approved) which seems to be correct. However, 4366 is already obsoleted by 5246 which may not be accurate. Actually can we have one RFC obsoleted by more that one newer RFC?

[Ballot comment]
The RFC Editor will require that you remove the citation from the
Abstract. This is usually done by replacing it with the document
name and RFC number.

[Ballot discuss]
I don't think it is right that Section 10.1 includes the text

  Published specification: [RFC4366], and [RFC5280].

yet this document claims to obsolete RFC 4366.

[Ballot comment]
I am agreeing with Peter's DISCUSS.

Additionally, I have the following comments:

10.1 pkipath MIME Type Registration


The "Encoding Considerations" section should say that the data is binary.


  Person & email address to contact for further information:
      Magnus Nystrom

I vaguely remember that Magnus has changed jobs since, so this email address is no longer valid.

[Ballot discuss]
This is an important document and I support its publication. However I would like to discuss a few things before recommending its approval:

1)
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.

2)
5. Client Certificate URLs

  The TLS server is not required to follow HTTP redirects when
  retrieving the certificates or certificate chain.

This is not strong enough for interoperability. Either redirects MUST be followed, or they MUST NOT be followed. Alternatively there need to be some explanation of why SHOULD (or even MAY) is appropriate here.

  The URLs used in
  this extension SHOULD therefore be chosen not to depend on such
  redirects.

3)
5. Client Certificate URLs

  If a server encounters an unreasonable delay in obtaining

This is not very specific. Can a minimal value be recommended here?

  certificates in a given CertificateURL, it SHOULD time out and signal
  a certificate_unobtainable(111) error alert.

What are possible alternatives to the SHOULD?

  This alert MAY be fatal;
  for example, if client authentication is required by the server for
  the handshake to continue.

[Ballot comment]
I am agreeing with Peter's DISCUSS.

Additionally, I have the following comments:

10.1 pkipath MIME Type Registration

  Person & email address to contact for further information:
      Magnus Nystrom

I vaguely remember that Magnus has changed jobs since, so this email address is no longer valid.

[Ballot discuss]
This is an important document and I support its publication. However I would like to discuss a few things before recommending its approval:

1)
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.

2)
5. Client Certificate URLs

  The TLS server is not required to follow HTTP redirects when
  retrieving the certificates or certificate chain.

This is not strong enough for interoperability. Either redirects MUST be followed, or they MUST NOT be followed. Alternatively there need to be some explanation of why SHOULD (or even MAY) is appropriate here.

  The URLs used in
  this extension SHOULD therefore be chosen not to depend on such
  redirects.

3)
5. Client Certificate URLs

  If a server encounters an unreasonable delay in obtaining

This is not very specific. Can a minimal value be recommended here?

  certificates in a given CertificateURL, it SHOULD time out and signal
  a certificate_unobtainable(111) error alert.

What are possible alternatives to the SHOULD?

  This alert MAY be fatal;
  for example, if client authentication is required by the server for
  the handshake to continue.

[Ballot discuss]
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).

[Ballot comment]
== Unused Reference: 'RFC2119' is defined on line 1027, but no explicit
    reference was found in the text

  -- Obsolete informational reference (is this intentional?): RFC 2246
    (Obsoleted by RFC 4346)

  -- Obsolete informational reference (is this intentional?): RFC 4346
    (Obsoleted by RFC 5246)

  -- Obsolete informational reference (is this intentional?): RFC 4366
    (Obsoleted by RFC 5246)

IANA questions/comments:

The document has not been updated to answer all the questions we had
during the first Last Call. Specifically:

- Do you want the references to RFC4366 in the "Transport Layer
Security (TLS) Parameters" registry changed to point to this
document? The current document only asks to change the references
in the "Transport Layer Security (TLS) Extensions" registry. (See
section 2)

- Do you want the MIME registry entry application/pkix-pkipath updated
to refer to this document?


Upon approval of this document, the IANA will make the following
changes in "Transport Layer Security (TLS) Extensions" registry located at
http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
sub-registry "ExtensionType Values"

OLD:

Value Extension name Reference
----- -------------- ---------
0 server_name [RFC4366]
1 max_fragment_length [RFC4366]
2 client_certificate_url [RFC4366]
3 trusted_ca_keys [RFC4366]
4 truncated_hmac [RFC4366]
5 status_request [RFC4366]


NEW:

Value Extension name Reference
----- -------------- ---------
0 server_name [RFC4366],[RFC-tls-rfc4366-bis-09]
1 max_fragment_length [RFC4366],[RFC-tls-rfc4366-bis-09]
2 client_certificate_url [RFC4366],[RFC-tls-rfc4366-bis-09]
3 trusted_ca_keys [RFC4366],[RFC-tls-rfc4366-bis-09]
4 truncated_hmac [RFC4366],[RFC-tls-rfc4366-bis-09]
5 status_request [RFC4366],[RFC-tls-rfc4366-bis-09]


We understand the above to be the only IANA Action for this document.

IANA questions/comments:

- Do you want to update the Handshake Type registrations of the
certificate_url and certificate_status from RFC4366 to this
document?

- Do you want to update the TLSAlert registrations of
unsupported_extension, certificate_unobtainable, unrecognized_name,
bad_certificate_status_response, and bad_certificate_hash_value from
RFC4366 to this document?

- Do you want to update the application/pkix-pkipath registration from
RFC4366 to this document?

Upon approval of this document, IANA will make the following
changes in the "ExtensionType Values" registry at
http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml

OLD:

Value Extension name Reference
----- --------------- ---------
0 server_name [RFC4366]
1 max_fragment_length [RFC4366]
2 client_certificate_url [RFC4366]
3 trusted_ca_keys [RFC4366]
4 truncated_hmac [RFC4366]
5 status_request [RFC4366]


NEW:

Value Extension name Reference
----- --------------- ---------
0 server_name [RFC-ietf-tls-rfc4366-bis-05]
1 max_fragment_length [RFC-ietf-tls-rfc4366-bis-05]
2 client_certificate_url [RFC-ietf-tls-rfc4366-bis-05]
3 trusted_ca_keys [RFC-ietf-tls-rfc4366-bis-05]
4 truncated_hmac [RFC-ietf-tls-rfc4366-bis-05]
5 status_request [RFC-ietf-tls-rfc4366-bis-05]


We understand the above to be the only IANA Action for this document.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Joe Salowey, TLS WG co-chair, is the document shepherd for this
document, draft-ietf-tls-rfc4366-bis-05,  and believes it is ready for
publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

The document has had adequate review.  The document shepherd does not
have any concerns about the breadth  of reviews.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

no

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

There is no IPR disclosure specifically for this draft, however RFC 4366
is listed as related material for  the Certicom IPR Disclosure
https://datatracker.ietf.org/ipr/1154/.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 


There as a good amount of consensus around this document within the
working group.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts
Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are

        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Yes

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

The references are split between normative and informative.  Downrefs
are informational.


  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The document does not define any new registries or values, it does
however update the reference from  previous the previous RFC 4366 to
this one. 


  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

Not Applicable.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

This document provides specifications for existing TLS extensions. It is
a companion document for the TLS  1.2 specification [RFC5246]. The
extensions specified are server_name, max_fragment_length,
client_certificate_url, trusted_ca_keys, truncated_hmac, and
status_request.  This document obsoletes RFC  4366.


    Working Group Summary

This is an update of an existing document to fit the new partitioning of
material between the base spec and  the extensions spec. There were some
technical changes that were discussed extensively in the working  group.
The document represents the current consensus of the working group.



    Document Quality

A number of extensions in the document have been implemented by several
parties.  Many of the implementers  participate in the TLS working group
and have contributed to the discussion of the document.