Transport Layer Security (TLS) Extensions
draft-ietf-tls-rfc3546bis-02

[Ballot comment]
Replied to an email from Ekr, cc Russ, where these points were acked, and revision
based on them promised.  Clearance of Discuss, since there was no failure to
communicate, seemed very reasonable.

STRONG NOTE:  I'm aware of (am an author of) the IESG DIscuss Criteria.  I
do not raise an issue on my second review of a document in a light way. 
My points below relate to deployment and upgrade, and an unclear spec
could trip those up.  That was why I judged it worthy to reopen, not unthinkingly.

My former Discuss:
Two issues I seem to have missed in reviewing 3546, which may still be timely, since
the writeup says there is not so much deployment, and they relate to
the questions about implementations that do and don't support extensions.

1. There should be more about servers with no support of the extensions
mechanism.  The bottom of page 3/top of page 4 states that such servers
present no problem of interoperability, which I agree seems likely, but I'd
like the spec to give more information.  What are the actions a client should
take on receiving from the server (and are the expected failures from
these servers well-distinguished enough from other kinds of failure so that
trying again with an unextended hello will be clearcut where this is appropriate?
The Security ADs have stated in the discussion of the document that there is
nothing hard here, so I'm asking only for exposition it seems.


2. About the extension control design, the following description of future things to
come is not clear:

  Nonetheless "server initiated" extensions may be provided in the
  future within this framework - such an extension, say of type x,
  would require the client to first send an extension of type x in the
  (extended) client hello with empty extension_data to indicate that it
  supports the extension type.

What would be empty about the client's offering, so that the server response
would be the "initiation"?  If this paragraph does not communicate more, should
it remain in the document?   

A compliment:  I really like the list of considerations about extension design in
Section 5.  They are very well thought out.

[Ballot comment]
Replied to an email from Ekr, cc Russ, where these points were acked, and revision
based on them promised.  Clearance of Discuss, since there was no failure to
communicate, seemed very reasonable.

Two issues I seem to have missed in reviewing 3546, which may still be timely, since
the writeup says there is not so much deployment, and they relate to
the questions about implementations that do and don't support extensions.

1. There should be more about servers with no support of the extensions
mechanism.  The bottom of page 3/top of page 4 states that such servers
present no problem of interoperability, which I agree seems likely, but I'd
like the spec to give more information.  What are the actions a client should
take on receiving the failure from the server (and are the expected failures from
these servers well-distinguished enough from other kinds of failure so that
trying again with an unextended hello will be clearcut where this is appropriate?
The Security ADs have stated in the discussion of the document that there is
nothing hard here, so I'm asking only for exposition it seems.


2. About the extension control design, the following description of future things to
come is not clear:

  Nonetheless "server initiated" extensions may be provided in the
  future within this framework - such an extension, say of type x,
  would require the client to first send an extension of type x in the
  (extended) client hello with empty extension_data to indicate that it
  supports the extension type.

What would be empty about the client's offering, so that the server response
would be the "initiation"?  If this paragraph does not communicate more, should
it remain in the document?   

A compliment:  I really like the list of considerations about extension design in
Section 5.  They are very well thought out.

[Ballot discuss]
Two issues I seem to have missed in reviewing 3546, which may still be timely, since
the writeup says there is not so much deployment, and they relate to
the questions about implementations that do and don't support extensions.

1. There should be more about servers with no support of the extensions
mechanism.  The bottom of page 3/top of page 4 states that such servers
present no problem of interoperability, which I agree seems likely, but I'd
like the spec to give more information.  What are the actions a client should
take on receiving the failure from the server (and are the expected failures from
these servers well-distinguished enough from other kinds of failure so that
trying again with an unextended hello will be clearcut where this is appropriate?
The Security ADs have stated in the discussion of the document that there is
nothing hard here, so I'm asking only for exposition it seems.


2. About the extension control design, the following description of future things to
come is not clear:

  Nonetheless "server initiated" extensions may be provided in the
  future within this framework - such an extension, say of type x,
  would require the client to first send an extension of type x in the
  (extended) client hello with empty extension_data to indicate that it
  supports the extension type.

What would be empty about the client's offering, so that the server response
would be the "initiation"?  If this paragraph does not communicate more, should
it remain in the document?   

A compliment:  I really like the list of considerations about extension design in
Section 5.  They are very well thought out.

[Ballot discuss]
Two issues I seem to have missed in reviewing 3546, which may still be timely, since
the writeup says there is not so much deployment, and they relate to
the questions about implementations that do and don't support extensions.

1. There should be more about servers with no support of the extensions
mechanism.  I'll be happy to be shown where it is handled other than
obliquely here:

  A server that supports the extensions mechanism MUST accept only
  client hello messages in either the original or extended ClientHello
  format,  and (as for all other messages) MUST check that the amount of
  data in the message precisely matches one of these formats; if not
  then it MUST send a fatal "decode_error" alert.  This overrides the
  "Forward compatibility note" in [TLS].


is the client sending extended ClientHello
supposed to use the fatal "decode_error" alert to decide that the server does not
support extension mechanisms and then decide whether to try a non-extended
hello?  It seems also that spec should mention this case, also indicating
to authors of future extensions that their clients may need guidance on go/no go
in that situation. 

2. About the extension control design, the following description of future things to
come is not clear:

  Nonetheless "server initiated" extensions may be provided in the
  future within this framework - such an extension, say of type x,
  would require the client to first send an extension of type x in the
  (extended) client hello with empty extension_data to indicate that it
  supports the extension type.

What would be empty about the client's offering, so that the server response
would be the "initiation"?  If this paragraph does not communicate more, should
it remain in the document?   

A compliment:  I really like the list of considerations about extension design in
Section 5.  They are very well thought out.

[Ballot discuss]
Two issues I seem to have missed in reviewing 3546, which may still be timely, since
the writeup says there is not so much deployment, and they relate to
the questions about implementations that do and don't support extensions.

1. There should be more about servers with no support of the extensions
mechanism.  I'll be happy to be shown where it is handled other than
obliquely here:

  A server that supports the extensions mechanism MUST accept only
  client hello messages in either the original or extended ClientHello
  format,  and (as for all other messages) MUST check that the amount of
  data in the message precisely matches one of these formats; if not
  then it MUST send a fatal "decode_error" alert.  This overrides the
  "Forward compatibility note" in [TLS].


is the client sending extended ClientHello
supposed to use the fatal "decode_error" alert to decide that the server does not
support extension mechanisms and then decide whether to try a non-extended
hello?  It seems also that spec should mention this case, also indicating
to authors of future extensions that their clients may need guidance on go/no go
in that situation. 

2. About the extension control design, the following description of future things to
come is not clear:

  Nonetheless "server initiated" extensions may be provided in the
  future within this framework - such an extension, say of type x,
  would require the client to first send an extension of type x in the
  (extended) client hello with empty extension_data to indicate that it
  supports the extension type.

What would be empty about the client's offering, so that the server response
would be the "initiation"?  If this paragraph does not communicate more, should
it remain in the document?   

A compliment:  I really like the list of considerations about extension design in
Section 5.  They are very well thought out.

[Ballot discuss]
The extensions and the mechanism seem very valuable, and I'll be happy to see
this well-written document go forward.

Two issues, and one procedure question.

1. There should be more about servers with no support of the extensions
mechanism.  I'll be happy to be shown where it is handled other than
obliquely here:

  A server that supports the extensions mechanism MUST accept only
  client hello messages in either the original or extended ClientHello
  format,  and (as for all other messages) MUST check that the amount of
  data in the message precisely matches one of these formats; if not
  then it MUST send a fatal "decode_error" alert.  This overrides the
  "Forward compatibility note" in [TLS].


is the client sending extended ClientHello
supposed to use the fatal "decode_error" alert to decide that the server does not
support extension mechanisms and then decide whether to try a non-extended
hello?  It seems also that spec should mention this case, also indicating
to authors of future extensions that their clients may need guidance on go/no go
in that situation. 

2. About the extension control design, the following description of future things to
come is not clear:

  Nonetheless "server initiated" extensions may be provided in the
  future within this framework - such an extension, say of type x,
  would require the client to first send an extension of type x in the
  (extended) client hello with empty extension_data to indicate that it
  supports the extension type.

What would be empty about the client's offering, so that the server response
would be the "initiation"?  If this paragraph does not communicate more, should
it remain in the document?   

A compliment:  I really like the list of considerations about extension design in
Section 5.  They are very well thought out.


3. Procedure question:  did the mime type have an ietf-types review?  Didn't see it
go by or find in my archive.  The community settled it wants to look at these, as well
having the IESG approval for them.

[Ballot discuss]
Overall, I felt this document was very good, and I really appreciate the time folks have put into the Security Considerations around the use of different URI schemes.  There were two areas I wanted to
ask for further discussion on:

The document currently says:

  The detailed security concerns involved will depend on the URL
  schemes supported by the server.  In the case of HTTP, the concerns
  are similar to those that apply to a publicly accessible HTTP proxy
  server.  In the case of HTTPS, the possibility for loops and
  deadlocks to be created exists and should be addressed.  In the case
  of FTP, attacks similar to FTP bounce attacks arise.

It wasn't clear what the benefit was to leaving the set of URI schemes open;
a limited set (such as http, https, and ftp) at least as an initial set seems easier.
Would it make sense to create such a limitation and then leave open the possibility
of later amendment, perhaps with a registry?

The document also says:

  Also note that HTTP caching proxies are common on the Internet, and
  some proxies do not check for the latest version of an object
  correctly.  If a request using HTTP (or another caching protocol)
  goes through a misconfigured or otherwise broken proxy, the proxy may
  return an out-of-date response.

Would it make sense here to include a reference to the cache-control directives
in RFC 2616?  I'm thinking, in particular, of this text from 13.1.16:

  A client's request MAY specify the maximum age it is willing to
  accept of an unvalidated response; specifying a value of zero forces
  the cache(s) to revalidate all responses.

That won't help broken caching proxies, naturally, but it may help with
those that are not.

Also, I wonder if the group would consider adding text on what to do
in the HTTP case when a redirect occurs.  In particular, would it make
sense to consider how the presence of a hash would change expected
behavior for that (so that a redirected reference whose hash could be
checked might be accepted where one that could not would not?)

[Ballot discuss]
draft-ietf-tls-rfc3546bis is intended to update RFC 2246 and obsolete 3546.  2246 has itself been obsoleted by draft-ietf-tls-rfc2246-bis, which is in the RFC Editor queue.  What's the point of updating an obsolete specification?  Why would this document not update draft-ietf-tls-rfc2246-bis instead of 2246?

[Ballot comment]
Minor  : The MIME type registration in the IANA
section should list IESG as change controller.


My major concern is that the uses of SHA-1 in this protocol do not
provide for algorithm agility.  I think the trusted CA indication is
probably OK, because a new identifier can be defined for new hashes of
keys and for new hashes of certificates.  However the client
certificate URL extensions seem like they need better algorpithm
agility.  First, it seems like the server could tell the client what
hashes it supports in its response to the extension indicating
support.  Second, it seems like the client's choice of hash algorithm
should be identified rather than being hard coded to sha-1.

The downgrade attack issues surrounding this proposed change would
need to be considered.

IANA Last Call Comments:
Upon approval of this document the IANA will create a new registry for ExtensionType values.  It is not clear as to what the initial list of values are (even after looking in section 2.3).  Can a list be put in the IANA Consideration section of what to populate the registry with?

The IANA will also change the reference for the MIME Media Type pkix-pkipath
to be this document.