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

Loganaden Velvindron <> Tue, 10 November 2020 19:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE5B43A0EDA for <>; Tue, 10 Nov 2020 11:58:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cPcPjXcFDBme for <>; Tue, 10 Nov 2020 11:58:25 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::f30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7829F3A10CF for <>; Tue, 10 Nov 2020 11:58:17 -0800 (PST)
Received: by with SMTP id ek7so2737851qvb.6 for <>; Tue, 10 Nov 2020 11:58:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/MVXgH1O7o7DML5FUhiB4md+3SaQTzXgX6WMlIEIFgw=; b=bWFrO04mvbQR80DCsFYiYzKSt7ntvdZwYTUJ4VrFRf4Ir9WGHeeUsWuVEEb5NmyjZv 7ttaXX8KITf09s6vzIuj6E7if5KHo8eF4u4codc8JDA1f9JPoU4C5a3yjlVs+B2nLnb3 ffNslWLAiOMscizRuZqXy5W3yKdatKzs3q5mhhhDbRuDa/LRHKLE/TuwUhpKBrKs8tYz rGOa9qNngQBcBQ4CKE2Mk65juSOeJmVkqOqubIoqgtNbntg17AmwknKQYP75WwlRfSVq EvIS5w5ikQF/gcc0xe3SaH/NMoG3EXxGy5au5TLGuaM6aZZkIOCsAbKXrpnXVH3JSzmu OXxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/MVXgH1O7o7DML5FUhiB4md+3SaQTzXgX6WMlIEIFgw=; b=SgEmWLsb9lkLoZosppksICF2sdT7YjRynYmG/w4WGuQL3TBEyK10sg1jJh+nzeJCCQ ze0/Kg1jRHpSvVc41J86howQMqWhSg0lhMbJ8J0QrhOcDhhT7CR0CuyO9zTAcOJUr7uK bZ4INVOmJ6ldEtbbmrrYgJcvji0AnXl2OVG1CaAnhbLzuVaZD6RikEeJMlBVvJ4Hkhdu l481VbUpZ67N/93rYHTZ60F5+MNgfVKNj8vzotj4SXwjw35/+hFDJ9VaOOTOZo2dgDGW EOq0sf4VYX2YqOxpzX0fhrlOIdA6kfk6k3dq1ixAw682T3amjm+ZRQjmtKCEmW9FatZs rfFQ==
X-Gm-Message-State: AOAM5301kM6ov3TuFY/09e7SR1nvX5bRFOGgYQ5lm1Qp1Y/mGZr0p1Sl ZR5ckim2AWh6NxIlr3+eHMftWzngPrKWeJSm7ZA=
X-Google-Smtp-Source: ABdhPJzlAlH8rNCFBdSVwNGhnvSqNFAFXnsAbU3p/+jcV6n58UeQKYswudKQ6zE1BfJMwLyBbnMvFiL6RvM5cOUtQwU=
X-Received: by 2002:ad4:5345:: with SMTP id v5mr21505819qvs.15.1605038296480; Tue, 10 Nov 2020 11:58:16 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Loganaden Velvindron <>
Date: Tue, 10 Nov 2020 23:58:05 +0400
Message-ID: <>
To: Yaron Sheffer <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [TLS] Obsoleting SCSV in draft-ietf-tls-oldversions-deprecate
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Nov 2020 19:58:27 -0000

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


  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


> 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