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

Sean Turner <> Tue, 08 October 2019 00:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D5E2612010E for <>; Mon, 7 Oct 2019 17:30:54 -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, 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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1YcH_uhSZHb2 for <>; Mon, 7 Oct 2019 17:30:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC5B3120111 for <>; Mon, 7 Oct 2019 17:30:51 -0700 (PDT)
Received: by with SMTP id q203so14681571qke.1 for <>; Mon, 07 Oct 2019 17:30:51 -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=lCqBAHbu8UHwO90yKi5ZB42Wlg89A4+5KRH7/kn0uP4=; b=aQIJVSDxBTRKpdYb8PydBNkkpN/ZrxrY61L12jmhMZ8bCNggpl35muLfwcoNGw3HOz qzAT88lygkYTr1tEe28iOpKz8cbKn4UkJ6M/d2ZdrPlh+ujw+yoUu0IMtCY3sOb+Tf4Z z8RhIlXEu33dTbhMmbA3pgq/SlMXOIVmjmpmk=
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=lCqBAHbu8UHwO90yKi5ZB42Wlg89A4+5KRH7/kn0uP4=; b=eQteYvXgTUUsDR0pJIK+pl8dHkFYl9VdmRxvtKCPm3xrMYyZ3GlWBNf12Z4GynqfQd HCYK737wRedpduKv7diURaJ3PdidYn+o6Hhv5+I3Auc/G4FG4qOcRk721111zj1GMkDi IynfHBWpNHOEAPM8YtSl4ZKdQAeSHg8OH1/U9N9IFsLsmfUs7gbw96O96J4DKPso+r5s t0O2dxfxa+CTgKj1uULLsiKmf+oziV9Acrq0Nok9fBY4Ln8XGHS3OujX13VMRaciaOos VHRjwrhFMFQQ0Zj3EhLTa1eH9oeWRyN878bwnlOsh1blJFOhI5mpz/+xHWcRcmiU5QAf AhMA==
X-Gm-Message-State: APjAAAVj5hUsm/qIGTIrdclhrV+FensCT78w9g+otRXcjTAhIYa88dTQ mlhMxXQdfPzS4EFoEQk1bhECf8qWTsE=
X-Google-Smtp-Source: APXvYqw7fC2Fqh0Jnf01WRaJcglXlpFTN2FuO/Z8qE/6ijFst89UGevB1hncpi3qHY74Dg3l/WWN+w==
X-Received: by 2002:a37:9d3:: with SMTP id 202mr26784293qkj.391.1570494650700; Mon, 07 Oct 2019 17:30:50 -0700 (PDT)
Received: from sn3rd.lan ([]) by with ESMTPSA id x19sm8096501qkf.26.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Oct 2019 17:30:49 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sean Turner <>
In-Reply-To: <>
Date: Mon, 7 Oct 2019 20:30:47 -0400
Cc: John Mattsson <>, IESG Secretary <>, "" <>,, Benjamin Kaduk <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
To: "" <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05
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, 08 Oct 2019 00:30:55 -0000

> On Oct 7, 2019, at 16:12, Stephen Farrell <> wrote:
> Hiya,
> On 07/10/2019 18:29, Rob Sayre wrote:
>> On Tue, Oct 1, 2019 at 7:34 PM Stephen Farrell <>
>> wrote:
>>> we can't "UPDATE" an I-D.
>> Not true. If you need to refer to something that's been IESG-approved but
>> still in the RFC queue, you can leave a note for the RFC editor to update
>> the reference to the eventual RFC number.
> That would be an UPDATE on the eventual RFC and not on the
> I-D. And in this case, it'd IMO not be a good plan as a) the
> relevant WG didn't want that, b) the I-D in question is part
> of a mega-cluster, so any dependency on it (as you suggest)
> risks loadsa delay if the cluster doesn't get unstuck, which
> can happen and c) our draft already stretches the header
> enough updating 85 RFCs - trying to add an I-D to that list
> would break tools and cause much pointless process-angst.
> Mostly (a) is the reason to not do it though. If you want
> to disagree with (a), then the right list for that would be
> the rtcweb list I guess, even though the WG is now concluded
> (which could, I guess, be (d);-)
> Overall, the cost isn't worth the benefit IMO.

draft-ietf-rtcweb-security-arch shepherd hat on

To ekr’s point, the decision to make that switch I think actually pre-dated me.  But before I go off and dig up the history, I think we should consider what an "updates” in terms of draft-ietf-tls-oldversions-deprecate would be.  First the 2119 requirement in draft-ietf-rtcweb-security-arch is as follows:

   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].   

The rest of the quote contains no 2119 language and is merely an informative statement:

   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. 

So, draft-ietf-tls-oldversions-deprecate would say nothing about DTLS1.2 because DTLS1.2 is not being deprecated.  It could update the informative statement to say something else, but it is a factual statement.  Maybe changing the last sentence to say “... which support only DTLS 1.0 might encounter interoperability issues” sounds somehow better, but maybe this is better just leave it alone.