Re: [TLS] RFC5746: Renegotiation Indication for minimal servers

["Bauer Johannes (HOME/EFS)" <[e-mail]>]

Hi Ben,

On Tue, Aug 2, 2016 at 17:05, Benjamin Kaduk wrote:
> The next step is for someone to write proposed text that would be more clear.
> Maybe you have thoughts about how things could change?

Sure, I can give it a shot. Below is my proposal. Curious to hear your
thoughts on it. I propose slight wording changes in three parts and a new
Sect. 4.6 which sums up what is to do for minimal implementations.

Cheers,
Johannes



Sect. 3.4 (Client Behavior: Initial Handshake)

   o  When the handshake has completed, the client needs to save the
      client_verify_data and server_verify_data values for future use.

could be clarified as follows:

   o  When the handshake has completed, a client that supports renegotiation
      needs to save the client_verify_data and server_verify_data values for
      future use.



Sect. 3.6 (Server Behavior: Initial Handshake)

   o  When the handshake has completed, the server needs to save the
      client_verify_data and server_verify_data values for future use.

could be clarified as follows:

   o  When the handshake has completed, a server that supports renegotiation
      needs to save the client_verify_data and server_verify_data values for
      future use.



Sect 4.3 (Server Considerations)

   In order to enable clients to probe, even servers that do not support
   renegotiation MUST implement the minimal version of the extension
   described in this document for initial handshakes, thus signaling
   that they have been upgraded.

could be clarified as follows:

   In order to enable clients to probe, even servers that do not support
   renegotiation MUST implement the minimal version of the extension
   described in this document for initial handshakes, thus signaling
   that they do not suffer from an insecure renegotiation vulnerability.



New Sect 4.6 (Minimal Implementation)

   Signaling that insecure renegotiation is not supported is a useful effect
   of the adaptation of this RFC regardless of whether or not a specific
   implementation supports renegotation or not. Since minimal implementations
   typically do not support renegotation, they also are implicitly not
   vulnerable to the attacks described in the beginning of this document.

   Therefore it is sufficient for clients that do not support any kind of
   renegotation to simply include the TLS_EMPTY_RENEGOTIATION_INFO_SCSV
   signaling cipher suite value in the ClientHello, as described in Sect. 3.4.

   For TLS servers which do not support renegotiation, it is sufficient to
   parse ClientHello messages for either the
   TLS_EMPTY_RENEGOTIATION_INFO_SCSV signaling cipher suite value or an empty
   renegotiation_info TLS extension. In either cases, the server MUST respond
   with an empty renegotation_info TLS extension, as described in Sect. 3.6.

   Neither servers nor clients which do not support renegotiation will
   therefore have the need to store additional variable data in memory during

   runtime.


--
Johannes Bauer

Engineering Field Services (HOME/EFS)
Robert Bosch Smart Home GmbH | Schockenriedstr. 17 | 70565 Stuttgart-Vaihingen | GERMANY | www.bosch-smarthome.com<http://www.bosch-smarthome.com>
Tel. [phone] | [e-mail]
Registergericht: Amtsgericht Stuttgart, HRB 754585;
Geschäftsführung: Dr. Peter Schnaebele, Veronika Danner