Re: [TLS] Metadiscussion on changes in draft-ietf-tls-renegotiation

[Martin Rex <[e-mail]>]

[e-mail] 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