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

[Sean Turner <[e-mail]>]

Any more thoughts on these?

spt

> On Aug 03, 2016, at 09:59, Bauer Johannes (HOME/EFS) <[e-mail]> wrote:
> 
> 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
> Tel. [phone] | [e-mail]
> Registergericht: Amtsgericht Stuttgart, HRB 754585; 
> Geschäftsführung: Dr. Peter Schnaebele, Veronika Danner 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls