On Tue, Nov 10, 2020 at 10:41 PM Yaron Sheffer <yaronf.i...@gmail.com> wrote: > > Hi, > > We are now revising RFC 7525 for the new world, and in general we are > following this draft. So, MUST NOT negotiate TLS 1.0 and 1.1. This brought up > the question of SCSV, which was new when RFC 7525 was published but has since > been widely implemented/deployed. > > I think marking the “oldversions” draft as “obsoletes RFC 7507 (SCSV)” is not > great from an ecosystem point of view. People will interpret it as “no need > to implement SCSV in new code, no need to expose it as a configuration option > in existing code”. And we know that some admins will continue to allow > downgrade to TLS 1.0/1.1 no matter what we tell them. IMO we should protect > these people from downgrade attacks, even if we disagree with their policy. > > So I would call for a more nuanced wording re: SCSV, something like > (paraphrasing EKR): >
Not everybody was happy to implement SCSV: e.g LibreSSL. From: https://v4.freshbsd.org/commit/openbsd/src/9t8bOP5HFWMq1Big " Reluctantly add server-side support for TLS_FALLBACK_SCSV. This allows for clients that willingly choose to perform a downgrade and attempt to establish a second connection at a lower protocol after the previous attempt unexpectedly failed, to be notified and have the second connection aborted, if the server does in fact support a higher protocol. TLS has perfectly good version negotiation and client-side fallback is dangerous. Despite this, in order to maintain maximum compatability with broken web servers, most mainstream browsers implement this. Furthermore, TLS_FALLBACK_SCSV only works if both the client and server support it and there is effectively no way to tell if this is the case, unless you control both ends. Unfortunately, various auditors and vulnerability scanners (including certain online assessment websites) consider the presence of a not yet standardised feature to be important for security, even if the clients do not perform client-side downgrade or the server only supports current TLS protocols. " > In the world where the only valid values of TLS are 1.2 and 1.3+, the TLS 1.3 > fallback mechanism should render the SCSV unnecessary. However for existing > client and server implementations that still include support for earlier TLS > versions, SCSV should continue to be supported. > > Thanks, > Yaron > > > _______________________________________________ > 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
