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