Transport Layer Security (TLS) Extensions
Note: This ballot was opened for revision 02 and is now closed.
(Russ Housley) Yes
(Brian Carpenter) No Objection
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Ted Hardie) (was Discuss) No Objection
(Sam Hartman) (was Discuss, No Objection, Discuss) No Objection
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.
(Scott Hollenbeck) (was Discuss) No Objection
(David Kessens) No Objection
(Allison Mankin) (was Discuss) No Objection
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.
(Jon Peterson) No Objection
(Mark Townsley) No Objection
(Bert Wijnen) No Objection
Comment (2005-08-31 for -)
I agree with Sam's COMMENT which he changed in a DISCUSS. So no need for me to take a further discuss.