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. +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
