Pasi.Eronen@xxxxxxxxx wrote: > > Martin Rex wrote: > > > I have never seen an IETF AD fight so passionately for the > > addition of rfc-2119-violating and unreasonable imperatives into > > a document such as Pasi is doing it now. > > "Now"? "Addition"? > > I would like to remind you that version -01 of the document also > very clearly prohibited sending the SCSV in secure renegotiation > ClientHello, and also used upper-case RFC 2119 keywords in that text. It could be that we are refering to different versions of -01, the one on tools.ietf.org doesn't have a MUST NOT send, and in particular, it does not have a MUST abort when received. If you think that there an implied MUST NOT in there -- I can see explicit MUSTs to the contrary in -01 and more so in -02! What to send on renegotiations has been returned to the WG as a discussion item, and that is also reflected by a pair of [TODO:] items in the document. -01 also has the following: 5. Requirements for Sending and Receiving TLS clients which support this draft MUST generate either the "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST cipher suite with every ClientHello. which is _NOT_ limited to *initial* ClientHellos. and -02 goes even further: 5. Requirements for Sending and Receiving TLS clients which support this specification MUST generate either the "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST SCSV with every ClientHello, including ClientHellos where session resumption is being offered. TLS servers MUST support both the "renegotiation_info" extension and the TLS_RENEGO_PROTECTION_REQUEST SCSV. TLS servers which support this specification MUST generate the "renegotiation_info" extension in the ServerHello in response to any client which offers either "renegotiation_info" or TLS_RENEGO_PROTECTION_REQUEST in the ClientHello. These are all of the MUST & MUST NOTs in -01 on tools.ietf.org: Upon receipt of the "renegotiation_info" extension, both client and server implementations which support the extension MUST verify that it contains the correct contents as specified above. If the contents are incorrect, then it MUST generate a fatal "handshake_failure" alert and terminate the connection. Servers MUST treat receipt of TLS_RENEGO_PROTECTION_REQUEST exactly as if the client had sent an empty "renegotiation_info" extension and respond with their own "renegotiation_info" extension. TLS implementations MUST continue to comply with 7.4.1.4 for all other extensions. Servers MUST NOT select this cipher suite in any handshake, as it does not correspond to any valid set of algorithms. Clients which do support renegotiation MUST implement Section 3 as well. TLS servers which support this draft MUST generate the "renegotiation_info" extension in the ServerHello in response to any client which offers either "renegotiation_info" or TLS_RENEGO_PROTECTION_REQUEST in the ClientHello. Existing implementations which do not support this extension are widely deployed and in general must interoperate with newer implementations which do support it. If clients wish to ensure that such attacks are impossible, they MUST terminate the connection immediately upon failure to receive the extension without completing the handshake. If servers wish to ensure that such attacks are impossible they MUST NOT allow clients who do not offer the "renegotiation_info" extension to renegotiate with them By default, TLS implementations conforming to this document MUST verify that once the peer has been identified and authenticated within the TLS handshake, the identity does not change on subsequent renegotiations. For certificate based cipher suites, this means bitwise equality of the end-entity certificate. If the other end attempts to authenticate with a different identity, the renegotiation MUST fail. If the server_name extension is used, it MUST NOT change when doing renegotiation. -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf