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

On Tue, Nov 10, 2020 at 10:41 PM Yaron Sheffer <yaronf.ietf@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