Re: [TLS] Obsolete SCSV!? (was Re: AD review of draft-ietf-tls-oldversions-deprecate-06)

Sean Turner <> Fri, 02 October 2020 17:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 906A13A116E for <>; Fri, 2 Oct 2020 10:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, PLING_QUERY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2tezpEU726fp for <>; Fri, 2 Oct 2020 10:44:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 197C53A116D for <>; Fri, 2 Oct 2020 10:44:22 -0700 (PDT)
Received: by with SMTP id g3so1932435qtq.10 for <>; Fri, 02 Oct 2020 10:44:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rgcBW+uguBS96CuOPf5CPe/UWPNsWYtkZS1gpJ198FA=; b=YvswpgXmVfN+j99LR73wjoei7CD8iR1Qg0/E/BLUJgNAvoduRKtN/o+uf1AcfwTHFA KA+15RZdyljRxWWpXZ9JlkFbKufJQz3OCmXXBY8k22ur7+hqvvI4MRV4EncQhm/FK3zh Bz0DtBJdksApTyTsx/v7swA2RvaWqr6/WSHoM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rgcBW+uguBS96CuOPf5CPe/UWPNsWYtkZS1gpJ198FA=; b=IXhiFBW/+A6mnboSw5CuaBfe744wEIu4liNkOC/S2AVIfIQLB5KwwiJIodar5h71gr /Q0nDKuKWLNew2qxmlAQxspFf/sjWvnNOm9Q0DNqV+dwvJcHsvJXjq0VbRhlEWxDSW63 wIV8R0sSs3WrSxfAW5+VG4JEILXYPDA/ayC0h6o1+QSMawMYJiPUAd21hF6MbU4JKkpg /Tw5PKJaCe/joEIpy8AtWLjq6ZZA7ylZUvLtMW8QExGOgbvmwWaLtCvSLX6zlokCcUA7 NQ+E6uSi0UBSYyihNKKRWjhbEoOAWlme/qyIdjqHzDzjVG9z2XCwP/qTF1Tpw9ivmZ+e mRQQ==
X-Gm-Message-State: AOAM531hqnH6u5VmWMVx8xcbQ4muTUaWxw+ABl1Fdj5K2OFliZy/er6T Pr8mhWbaQB6wBUPp0WJAv8Z1bS4W2jngSw==
X-Google-Smtp-Source: ABdhPJyorwESp87F9iUNFUC9xBlWGlYDRsLv607Hq1LGqVG3lz3HKD90gGNrlOHy11lhCUcMCj9Cag==
X-Received: by 2002:ac8:740a:: with SMTP id p10mr3370184qtq.171.1601660661355; Fri, 02 Oct 2020 10:44:21 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id g23sm1576978qta.42.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Oct 2020 10:44:20 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Sean Turner <>
In-Reply-To: <>
Date: Fri, 02 Oct 2020 13:44:18 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: TLS List <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [TLS] Obsolete SCSV!? (was Re: AD review of draft-ietf-tls-oldversions-deprecate-06)
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: Fri, 02 Oct 2020 17:44:25 -0000

> On Sep 23, 2020, at 08:43, Sean Turner <> wrote:
> Hi! this issue was buried in the Ben’s review, but I think it is worth getting some attention on.
>> On Aug 13, 2020, at 13:54, Benjamin Kaduk <> wrote:
>> On Wed, Aug 12, 2020 at 04:29:56PM -0400, Kathleen Moriarty wrote:
>>> On Sun, Jul 26, 2020 at 5:22 PM Benjamin Kaduk <> wrote:
>>>> - Similarly, the downgrade protection provided by the SCSV of RFC 7507
>>>> seems to be entirely obsolete.  Any implementation that is compliant
>>>> with this document will support only 1.2 or higher.  If it only
>>>> supports one version, no downgrade is possible; if it also supports
>>>> 1.3 or newer, the new downgrade-detection mechanism defined by TLS 1.3
>>>> applies, so the SCSV mechanism is entirely redundant (i.e., obsolete).
>>>> We could effectuate that status change in this document as well.
>>> Has this been addressed in RFC8446?  If not, the specific downgrade
>>> examples are just listed as examples.  If a gap is left, then the full
>>> document should not be deprecated and made obsolete.  The text infers other
>>> versions in my read.  I have not looked to see if this was addressed in
>>> RFC8446 yet though.
>> I'd really like to get a few more people to weigh in on this one -- IIRC
>> David Benjamin and Martin Thomson had mentioned some thoughts in the chat
>> during the session at 108, and Ekr as author of 8446 would be expected to
>> have a good sense of what it does.  
>> The specific RFC 8446 mechanism here is described at
>> : "TLS 1.3 has a
>> downgrade protection mechanism embedded in the server's random value.
>> [...]"
>> While the RFC 8446 mechanism has the client do the actual detection of
>> downgrade, there's a MUST-level requirement on clients to make the check,
>> so from a specification point of view the check can be treated as reliable.
>> The RFC 7507 mechanism has the server do the detection, but I think the end
>> result is still the same: in an "downgraded" exchange between two honest
>> participants, the handshake fails and the downgrade is detected.
>> Since the functionality is still useful, just superseded, this one seems
>> like a better fit for "obsoletes" (vs. "historic).
> Right now, we have a list of RFCs draft-ietf-tls-oldversions-deprecate will update. RFC 7507 "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks" ( is in this list. If you agree with Ben’s logic then we would be move 7507 out of the list of “updates” and adding an obsoletes header, i.e., “Obsoletes: 7507 (if approved)”, and moving 7507 down in s1.1 to the obsoletes paragraph. While this might seem like a minor point, this is the kind of the IESG loves to sink its teeth into so have a WG opinion on this matter can make overcoming later hurdles easier for the AD and doc shepherd.
> Thanks for the your time,
> spt (doc shepherd)

All I have gone ahead and submitted a PR to address the point raised by Ben: