Any more thoughts on these? spt
> On Aug 03, 2016, at 09:59, Bauer Johannes (HOME/EFS) > <johannes.ba...@bosch.com> 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. +49(711)81112906 | johannes.ba...@bosch.com > Registergericht: Amtsgericht Stuttgart, HRB 754585; > Geschäftsführung: Dr. Peter Schnaebele, Veronika Danner > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
