Subject: [TLS] Obsoleting SCSV in draft-ietf-tls-oldversions-deprecate

From: Yaron Sheffer <[email-masked]>
Date: Tue, 10 Nov 2020 20:40:57 +0200

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):

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

---

From: Hanno Böck <[email-masked]>
Date: Tue, 10 Nov 2020 20:15:44 +0100

On Tue, 10 Nov 2020 20:40:57 +0200
Yaron Sheffer <[email-masked]> wrote:

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

Is this true?

To clarify: We're not talking about people supporting TLS 1.0/1.1 (of
which there are obviously still many), we're talking about clients
doing out-of-protocol downgrade dances where they will attempt to
connect via TLS 1.0/1.1 if TLS 1.2 connections fail. That's the only
scenario where SCSV is needed.
AFAIK the only clients that ever did these out of protocol downgrades
were browsers and they all disabled this behavior in the meantime.

I would assume it's very likely that SCSV serves no useful purpose today
and hasn't done so for years.

-- 
Hanno Böck
https://hboeck.de/

---

From: Loganaden Velvindron <[email-masked]>
Date: Tue, 10 Nov 2020 23:58:05 +0400

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

"

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls