Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05

Benjamin Kaduk <kaduk@mit.edu> Sun, 06 October 2019 16:42 UTC

Return-Path: <kaduk@mit.edu>
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 23532120147; Sun, 6 Oct 2019 09:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
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 wUVcbP_nsosJ; Sun, 6 Oct 2019 09:42:17 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A970A12013C; Sun, 6 Oct 2019 09:42:14 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x96Gg55f020327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 6 Oct 2019 12:42:08 -0400
Date: Sun, 06 Oct 2019 09:42:05 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Rob Sayre <sayrer@gmail.com>
Cc: Eric Rescorla <ekr@rtfm.com>, Cullen Jennings <fluffy@iii.ca>, "tls@ietf.org" <tls@ietf.org>, "tls-chairs@ietf.org" <tls-chairs@ietf.org>, John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, draft-ietf-rtcweb-security-arch.ad@ietf.org
Message-ID: <20191006164205.GW6722@kduck.mit.edu>
References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <CABcZeBOCzwLDEUyiqkDG0Qqaf652_+j1KBsJQJcJk2Lew_9wCw@mail.gmail.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> <CAChr6Sx4AVjkoKWiD2-cT2ZBNg=mKzeOX603gVs0f7vQ_FgN7A@mail.gmail.com> <CABcZeBNOVOBifOSnWdxSDTLizUUUn6ctLrBT43CHK+4B7KWGiQ@mail.gmail.com> <CAChr6SzT3GqmidPbmVjmrZX=u1UpBee4e8K2C-zHuNHEqgB7uQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAChr6SzT3GqmidPbmVjmrZX=u1UpBee4e8K2C-zHuNHEqgB7uQ@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/bcfZfZqqGBRld9jMQkpKuWovYUc>
Subject: Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05
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: Sun, 06 Oct 2019 16:42:19 -0000

On Fri, Oct 04, 2019 at 09:57:53PM +0700, Rob Sayre wrote:
> On Fri, Oct 4, 2019 at 9:48 PM Eric Rescorla <ekr@rtfm.com> wrote:
> 
> >
> >
> > On Fri, Oct 4, 2019 at 7:43 AM Rob Sayre <sayrer@gmail.com> wrote:
> >
> >> On Fri, Oct 4, 2019 at 9:08 PM Cullen Jennings <fluffy@iii.ca> wrote:
> >>
> >>>
> >>> I do not think you have consensus for that change to WebRTC - it was
> >>> discussed extensively. ...
> >>>
> >>
> >>  While that may be true, readers of this list might want to read a
> >> rationale, rather than just the results of a negotiation. Is there a
> >> rationale somewhere?
> >>
> >> It seems strange to put DTLS 1.0 (based on TLS 1.1) into new documents.
> >>
> >
> > A few points.
> >
> > 1. It doesn't pull it in. There's no reference and there's just an
> > informative statement.
> >
> 
> Shouldn't there be an informative reference?

I think that's largely a question for the sponsoring AD (CC'd) and the RFC
Editor.

> 
> > 2. There is a rationale. In fact, the relevant text pretty much is all
> > rationale.
> >
> >    All Implementations MUST support DTLS 1.2 with the
> >    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256
> >    curve [FIPS186 <https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20#ref-FIPS186>].  Earlier drafts of this specification required DTLS
> >    1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and
> >    at the time of this writing some implementations do not support DTLS
> >    1.2; endpoints which support only DTLS 1.2 might encounter
> >    interoperability issues.
> >
> >
> Yes, I read this section and I was wondering what the rationale was for the
> text: "endpoints which support only DTLS 1.2 might encounter
> interoperability issues." Is there some data behind this? I'm not
> suggesting a change in the draft without more information, but I do wonder
> how the WG came to agree on this text.

My assumption (I was not following the work) is that it was a well-known
fact among implementors at the time that some large implementations only
implemented DTLS 1.0.  Accordingly, "might encounter interoperability
issues" is a bland uncontroversial fact, in that context.  It's not clear
to me that we are adding much value revisiting the rtcweb WG's decisions
over here on the TLS WG without getting input from rtcweb about why they
put it that way in the first place...

-Ben