Yngve Nysaeter Pettersen wrote:
I prefer publishing the specification as-is.
Additional comment:
The SCSV is a temporary fallback, one that will not be needed when
clients enter strict mode, since when that happens servers have to
support the RI extension. Its use should therefore be kept to the
minimum needed to provide the extra security it is designed to provide.
IMO the only situations in which the SCSV should be sent are:
1) Initial connections when the server is known to not tolerate TLS
Extensions, or this is not known
And you're willing to put the client at risk by possibly connecting to a
vulnerable server which may have buffered input data from MitM and is
willing to renegotiate.
, and
2) During renegotiation with a server known not to support the RI
extension _and_ that does not tolerate TLS Extensions
In that case, you were already pwned at the initial connection.
, just in case this
is a MITM attack and the real server actually supports RI, in which case
we want the connection shut down. If the server tolerates extensions
then only the RI extension should be sent.
As a general-purpose TLS client:
1. Don't connect to a server without RI.
2. If you ignore (1), don't send SCSV when you renegotiate.
As a general-purpose TLS server:
1. Don't allow connections without RI.
2. If you ignore (1), don't renegotiate.
- Marsh
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf