Re: [TLS] Confirming consensus about one draft-ietf-tls-renegotiation detail

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.Eronen@xxxxxxxxx> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]