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

Sean Turner <sean@sn3rd.com> Wed, 23 September 2020 12:43 UTC

Return-Path: <sean@sn3rd.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627773A109D for <tls@ietfa.amsl.com>; Wed, 23 Sep 2020 05:43:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oqr4WKKuy-aN for <tls@ietfa.amsl.com>; Wed, 23 Sep 2020 05:43:06 -0700 (PDT)
Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B944D3A1099 for <tls@ietf.org>; Wed, 23 Sep 2020 05:43:06 -0700 (PDT)
Received: by mail-qv1-xf31.google.com with SMTP id cv8so11237265qvb.12 for <tls@ietf.org>; Wed, 23 Sep 2020 05:43:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fdpjYYpPj9ZGpC1lmIAnGfMiV6IGAbgxzX2fYsKG11Q=; b=UySPLjGdOeETXF6XM2uBzCpALXPfyNDYGOyt7CwGq+ei7Sytyg6UZsDuidsgwIEh41 M0XEkty64QJIUhtRcqe5yXfz5Eq6227CiX9myj7Nug2CTWyDjCn6RDBohjvfNjBTYeS/ SX6yuKt8odDdf9XNhLc/gP6aC10ycIOmBPqVU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fdpjYYpPj9ZGpC1lmIAnGfMiV6IGAbgxzX2fYsKG11Q=; b=klWUK0komhlZzUz3j569Vwqt4ejyMKTul8g6/ZpB4pVKOoBIY6j1vAtMbld3DLEtJD V58qzBecw6BMFlbKcscMu30Xow7o7YpsI8ZpX4Woifw3OdTnH1k+OEHTedR6djbzsqIl LZ6oli2WNolcXm5f4eyVOXWbziOw3dGHrjNubj3q0zRkWZuSmbqhwRlRdx1dzbNLg7NN prDMRgWbX3/RJgqdd28+FesSg7Np225FLznhSVxW/vKYYci1sabEnrOUG3CeSPEb2OW8 8VOKjda9XzeRf4ocspspZJ4EPUiW7uQmLLV/KufBf+dxWscyinW8IQBicwDtbz50AXd1 /JQw==
X-Gm-Message-State: AOAM533KnzF3lJeqmTGmVrWSTL1s8Rj3IKX5lPvTqPz8fw+ok0S4q0ge 56zGCkyf1OXvwwx3c4REYF9LwGjipOf/9Q==
X-Google-Smtp-Source: ABdhPJwloixBCBx3S3GHDkp4hEsQ0mKLxTX0mCsV9Vi+YyRsXFlRy2M2XcMUF0FfJ1kaq2IatN0Svg==
X-Received: by 2002:ad4:57a4:: with SMTP id g4mr10599718qvx.61.1600864985098; Wed, 23 Sep 2020 05:43:05 -0700 (PDT)
Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id a11sm14374657qto.2.2020.09.23.05.43.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Sep 2020 05:43:04 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <20200813175413.GY92412@kduck.mit.edu>
Date: Wed, 23 Sep 2020 08:43:03 -0400
Cc: draft-ietf-tls-oldversions-deprecate.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <47A50677-E2CB-44F4-8683-2B99EA97875D@sn3rd.com>
References: <20200726212223.GY41010@kduck.mit.edu> <CAHbuEH6YV5HyqEV7DbO=_-9yFEHTS3Q7nH_t=ap_xwzGK=vMWw@mail.gmail.com> <20200813175413.GY92412@kduck.mit.edu>
To: TLS List <tls@ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/yQkUvgty0AdMkvrfq-CiYJd2swE>
Subject: [TLS] Obsolete SCSV!? (was Re: AD review of draft-ietf-tls-oldversions-deprecate-06)
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Sep 2020 12:43:08 -0000

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 <kaduk@mit.edu> 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 <kaduk@mit.edu> 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
> https://tools.ietf.org/html/rfc8446#section-4.1.3 : "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" (https://datatracker.ietf.org/doc/rfc7507/) 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)