Pasi.Eronen@xxxxxxxxx wrote:
(wearing IETF Security Area Director hat) - Whether to prohibit sending the extension (in initial ClientHello), or require the magic cipher suite even if the extension is sent (in initial ClientHello): The consensus is again a bit rougher than we'd normally hope to see, but the current text (either is allowed) has more support (about 2/3 vs. 1/3), so we keep it. And again, I believe most participants prefer make some decision over continuing the discussion.
There is no need to prohibit sending an empty RI in an initial Client Hello. Would a server be required to abort if it received it? That doesn't seem like a good design. I've implemented RI + MCSV and the logic I used was to have a boolean for whether the peer is patched, plus a string to hold the received renegotiation_info. When a ClientHello is being processed, the flag is set to false and the string is cleared. Then if the MCSV is seen in the cipher suite list, the flag is set to true. Then when parsing the extensions, if RI is encountered, the flag is set to true and the renegotiation_info is extracted into the string. There is no need to have special cases for initial vs. renegotiation handshakes.
- There was some discussion on whether to add the magic cipher suite to patched renegotiation ClientHellos (in addition to the extension), too. I believe rough consensus is not to do this.
There is no need to prohibit sending the MCSV in a renegotiation Client Hello. Using the same logic above, all that it does is flip a bit in the server's state. If the client believes it is doing a renegotiation, then it will also send RI with verify_data, which will get processed as above.
- There was discussion about adding another C->S signaling method using the proposed version: if proposed version >= 1.3, and the negotiated version is <= 1.2, it means the client supports this draft (what happens if negotiated version is >= 1.3 would be specified in the TLS 1.3 spec). This would allow TLS >=1.3 clients to remove other signaling (magic cipher suite/extension) from initial ClientHellos (but requires extra code in the server). As Tom Petch (and others) noted, if we want to do this, it has to be done now (and can't be done when doing TLS 1.3). There was relatively little support for doing this, and rough consensus seems to keep the spec as is in this regard.
As a practical matter, any TLS 1.3 code will need to still send RI and MCSV since it will surely encounter older servers for a long while after that spec gets published. So it seems that this is unnecessary. Mike _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf