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

Loganaden Velvindron <loganaden@gmail.com> Fri, 02 October 2020 18:15 UTC

Return-Path: <loganaden@gmail.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 A60B73A1664; Fri, 2 Oct 2020 11:15:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, PLING_QUERY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 5lmfInW5RXHq; Fri, 2 Oct 2020 11:15:41 -0700 (PDT)
Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 31FDC3A1663; Fri, 2 Oct 2020 11:15:41 -0700 (PDT)
Received: by mail-qt1-x844.google.com with SMTP id d1so2092605qtr.6; Fri, 02 Oct 2020 11:15:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0EGzZGtDSQpEn57vHINemXZE+KIRqzofeQgBBpalXZc=; b=Nz0ALxfHSlzfA7Km6Dihc1w+vhEl5/GPndn2o0luriTKj4+yr8JArE87sVykzkgkJD bW+Gx6GvJKi1VuG/Fi1CdiJkUUWtcstQlAMgKA3CtYDxp9rJjOxKsdnNPvoFqLX7WtsW v/Vov+g2H4YFwfz1aGIcrOfvuSUq5SKi6ZprPLAywd6zbPQHnAEH3j31JrecSQd1DwBa KdSBxqGBA42JP4swK4d9UM0KURCcxMWO8Tu4W67SF8GQcQXz6kgUszvb1bwv1tj30no7 737tG4gzt16djFcwfhhj5EMGTsQmHtHz2QxhNf+e+arWuEJ2zeXrzouDUU6yM9arvUIu L0wA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0EGzZGtDSQpEn57vHINemXZE+KIRqzofeQgBBpalXZc=; b=sHPRcARxypc1/v6fpOQbRRI0AF309g7Bpd9psLgQ7cUz02av25bLlz2rtNFp3gQFYD tnsPBqeaz52exYETro0LseUVYNg/D51YXKXkRBLmF4X0J0bG2a5gLjdEyStu+C5niMzO AnFOZ16qGYZ85t2cFPxovqhf5hgbU1b6foVL/Nwgw8hA28BfGsAXYwKaWXTbgzSlHOFx 7vHf/ffHX2mmW2G5fD37Eu50ozEmSmmyXobfJ7EnYvrY4eHmwcc+vvROGUSSoaJVtiFc dQcDMTzEoUQV4oyECtd1a07q+1jEW7OstUPLYL2DmCiJdmIEq66MLybFXha0Lyv1dKdU ZhxA==
X-Gm-Message-State: AOAM531u1mIt1wpuKu9BTV/HgJvNWdrBWRDplJbXILYmwn5JDqtq1TSK LnBmVkWXg7Df+AKqXkpeYEpYd2l0REJejxTpR+QaMyg3l2o=
X-Google-Smtp-Source: ABdhPJyUw9L3hB1KlOvil0e1XJnrrnR6W8/ZolQOXTU5D7lV5YNLxk+kA24DalAL0+ZB0qjDlzaebp3AQGH90ORYMo0=
X-Received: by 2002:aed:3245:: with SMTP id y63mr3573516qtd.324.1601662539792; Fri, 02 Oct 2020 11:15:39 -0700 (PDT)
MIME-Version: 1.0
References: <20200726212223.GY41010@kduck.mit.edu> <CAHbuEH6YV5HyqEV7DbO=_-9yFEHTS3Q7nH_t=ap_xwzGK=vMWw@mail.gmail.com> <20200813175413.GY92412@kduck.mit.edu> <47A50677-E2CB-44F4-8683-2B99EA97875D@sn3rd.com> <247D1EB3-1314-44C0-911D-2D6D440357D8@sn3rd.com> <CAOp4FwRdP2VVXMSoJAyE9cmEvwdQ2TKgVC=e16rMW_Z2eWbWNg@mail.gmail.com>
In-Reply-To: <CAOp4FwRdP2VVXMSoJAyE9cmEvwdQ2TKgVC=e16rMW_Z2eWbWNg@mail.gmail.com>
From: Loganaden Velvindron <loganaden@gmail.com>
Date: Fri, 2 Oct 2020 22:15:28 +0400
Message-ID: <CAOp4FwTgOk7B0pDxK2yc4_vPVYJm-gn5wj2TvXjwhvXubNka2g@mail.gmail.com>
To: Sean Turner <sean@sn3rd.com>
Cc: TLS List <tls@ietf.org>, draft-ietf-tls-oldversions-deprecate.all@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/geka1EqTon1K_0kL8rVcwDe7gN4>
Subject: Re: [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: Fri, 02 Oct 2020 18:15:43 -0000

On Fri, Oct 2, 2020 at 10:11 PM Loganaden Velvindron
<loganaden@gmail.com> wrote:
>
> Please go ahead. I remembered a discussion (outside of the ietf) where
> not everybody agreed
> with it but reluctantly implemented it.
>

Found the commit message in 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.

"
> On Fri, Oct 2, 2020 at 9:44 PM Sean Turner <sean@sn3rd.com> wrote:
> >
> >
> >
> > > On Sep 23, 2020, at 08:43, Sean Turner <sean@sn3rd.com> 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 <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)
> >
> > All I have gone ahead and submitted a PR to address the point raised by Ben:
> > https://github.com/tlswg/oldversions-deprecate/pull/4
> >
> > spt
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls