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

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.

I agree with Sam's COMMENT which he changed in a DISCUSS.
So no need for me to take a further discuss.

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.