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
2) During renegotiation with a server known not to support the RI
extension _and_ that does not tolerate TLS Extensions, 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.
On Tue, 26 Jan 2010 09:49:06 +0100, <pasi.ero...@nokia.com> wrote:
If the recent discussions have caused you to change your mind (or we
have interpreted your preference incorrectly, or you were not on
either list), please send an email to the TLS WG mailing list by
Tuesday February 2nd. In your reply, please include one of the
following:
(1) I prefer publishing the specification as-is.
(2) I prefer *NOT* publishing the specification as-is, and instead
prefer changing the text so that including the SCSV in secure
renegotiation ClientHellos is allowed (but not required).
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
