Pasi(_dot_)Eronen(_at_)nokia(_dot_)com 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf