Yoav Nir wrote: > On Nov 30, 2009, at 5:37 PM, The IESG wrote: > >> The IESG has received a request from the Transport Layer Security WG >> (tls) to consider the following document: >> >> - 'Transport Layer Security (TLS) Renegotiation Indication Extension ' >> <draft-ietf-tls-renegotiation-01.txt> as a Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@xxxxxxxx mailing lists by 2009-12-14. Exceptionally, >> comments may be sent to iesg@xxxxxxxx instead. In either case, please >> retain the beginning of the Subject line to allow automated sorting. > > I oppose publishing the current draft. I strongly support it. I don't buy the claims that extension handling as required here is so hard to implement and all clients & servers need modification in any case. (Not that its really relevant, but writing that code would be much easier that reading the recent TLS list traffic;-) I also don't see any concrete benefit in not sending the verify data over the wire, but I do see more possibility for error in terms of how to incorporate that data if its not sent. My comments on -01 are below. While I'd like to see these addressed of course, I think progressing this document speedily is more important than resolving my comments. I think the same applies to all other comments that I've seen, both during IETF LC and on the TLS list since this problem was announced. Regards, Stephen. 1. The reference for the HTTP splicing attack is still a placeholder. "[REF]" 2. I don't see any particular reason why the ServerHello RI value contains both client and server values. I think it'd be marginally better if the server just sent its value since the current approach makes it easier for a server to mess up the ordering. 3. (Crossing page 5/6) It says the both "MUST verify" that the values are correct, but doesn't explicitly say how to verify the values, but just "as specified below" - where below? It might be good to be extra-clear here, and add e.g. "A correct value is one that was the verify_data of the Finished message from the previous TLS session, or else the "empty" value given above." or something like that. 4. I'm slightly concerned that middleboxes might barf on the new ciphersuite. Be good if someone had tested that in the wild, but I've not seen a mail that says that that's happened. (The test I mean is inclusion of a totally new ciphersuite value, not the inclusion of a previously-allocated-but-mostly-unused value.) 5. (Similar to above.) It'd be great if we had data to allow us to recommend either the RI in the initial handshake or else recommend the ciphersuite. I can see implementers not knowing what to do there, leading to a 50-50 split in terms of who does what, possibly leading to lack of interop. If it were up to me, I'd remove the ciphersuite and just go with the RI. 6. Is there an explicit statement somewhere that servers MUST support both the RI extension and the ciphersuite? If so, I skipped over it, so maybe highlighting it somehow would be good. If not, please add, so that someone generating tests from the RFC's "MUST" statements generates one for that. 7. 6.2 says: "If servers wish to <<avoid attack>> they MUST NOT <<do stuff>>" Isn't that equivalent to servers SHOULD NOT? I think a SHOULD NOT is better. (And that's the form used in section 7.) 8. I would be for removing the new requirement that the identity not change. This spec is in response to one thing and should only fix that thing. Any other considerations should not get the "emergency" treatment being applied here especially since there could be unforseen side-effects of the additional change. (E.g. some deployed application making use of an id-change.) 9. The security considerations and the introduction should include a statement that another mitigation that's useful in many cases is for a server to simply disallow all renegotiation and encourage implementers to allow deployments to control that. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf