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

Eric Rescorla <> Wed, 09 October 2019 13:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDA5A12010C for <>; Wed, 9 Oct 2019 06:04:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dg54XDB6BjZN for <>; Wed, 9 Oct 2019 06:04:47 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B85EA12010E for <>; Wed, 9 Oct 2019 06:04:46 -0700 (PDT)
Received: by with SMTP id w6so1615042lfl.2 for <>; Wed, 09 Oct 2019 06:04:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iHVhl7veIYFyvCr17xY8VgE+CSX9K8s0M8NEfbAsq0Y=; b=HOWviSJfP0bDplgzjXlZ/GcJEp4JEyALZaWES6P0y96Mrv9orUfCgKlEZRlhfppcJm Ft46RIiiDGy56p0kAKwgrfwnfIFryIrrXK+J+n7xly0kguqNk4xvqYywcjQ2T53xXMXh d1LQ08sqxOLq/PuuCgfyPRXnfUFHxQDhY/WlBryOUHCgOa0ivsgYc47slGNxyF2WFVmx LWEX7hL8slMLneguRDW7TvElnO8QlJ+DseHF3qhdmVUedeHKETF7TMoivr/G4esAQfQA IZzbPgmux3KcPcBi1+uhsqm3cXGr1hRMGKlgAJJwn18xyEC4qw9d0fJ3vFFtDbwNC3Ry lzsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iHVhl7veIYFyvCr17xY8VgE+CSX9K8s0M8NEfbAsq0Y=; b=Wk54u3Ccwn/de7FV04PVM+nU4bvtBZGkHFS4vvl3uXBlcrEkmuqjBN7nBUek08C1S9 4CC4gAddq2bxoov96zza7K8KhHDwnhuyjK11NsM5oZ6btVFKxF19xucIwbySOIpmArcc lsKiBIiqMkdaDASm5KIBY6qCb0hHHu3icTw+Uk32LZbAIZ450X5nlQhJ6FJhqC8bz5o+ RBW4tEKL1uK7SrO4MwHKne+NQj0iqyXXyYcvS6H76Pg/laxMyYy7zMv3IJgkDU75h1Ot xWXOcgg3iD2xK+xP9vTaVz+YNSLZzUXGhFAUbDmISnaSk94lmRYOOB0FmS3qGbW1lSd4 4AGg==
X-Gm-Message-State: APjAAAUOPtLa4h1clDUUt4+DauNIgiEWQvU6saB1nf64KJHVP2o981XQ FtxsdoXasXHHr0z6YEzGN45ahj3lloi58/seCibBBg==
X-Google-Smtp-Source: APXvYqwUTW5F1nsPOGYnHAH+3BvqI+X6RSagNv08H+digXVEw1gasWmM+uWxmhRFqQR6MapIyKD8Ri0LPeId5xXOZBY=
X-Received: by 2002:a19:23cc:: with SMTP id j195mr2030473lfj.91.1570626284830; Wed, 09 Oct 2019 06:04:44 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Wed, 9 Oct 2019 06:04:08 -0700
Message-ID: <>
To: Rob Sayre <>
Cc: Cullen Jennings <>, "" <>, Sean Turner via Datatracker <>, "" <>, John Mattsson <>, Benjamin Kaduk <>
Content-Type: multipart/alternative; boundary="000000000000c85664059479ed62"
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: Wed, 09 Oct 2019 13:04:50 -0000

On Wed, Oct 9, 2019 at 5:28 AM Rob Sayre <> wrote:

> On Wed, Oct 9, 2019 at 7:20 PM Eric Rescorla <> wrote:
>>> 1) it doesn't seem like a particularly valid claim to say that the
>>> document "doesn't pull" in DTLS 1.0 when the rationale for that claim is a
>>> missing reference.
>> Well I suppose you're entitled to your opinion, but no, I don't think
>> that's true. We have a very specific meaning for normative dependency and
>> in no way would this be one. At most this would be an informative reference.
>> In any case, this is not the proper place for this discussion. If you
>> want this document changed, you'll need to take it to the RTCWEB WG.
> Honestly, thank you for the sincere response.
> After I read more of the many relevant documents, it became clear
> that draft-ietf-tls-oldversions-deprecate says implementations MUST NOT
> negotiate DTLS 1.0, while RFC 6347 and draft-ietf-rtcweb-security-arch
> encourage negotiation that results in endpoints agreeing on DTLS 1.0.

We should take 6347 and draft-ietf-rtcweb-security-arch separately.

When we have protocol version X and we introduce X+1, we're almost never
saying "you shouldn't negotiate X", because that would totally break the
transition story. Rather, we're saying "X and X+1 can coexist". Then, once
X+1 becomes sufficiently popular that you no longer need to support X, we
can say "you shouldn't even support X" (whether we should say that depends
on the details of X). So, 6347 was totally reasonable at the time and I
expect the guidance in this document to override 6347 which all seems quite

draft-ietf-rtcweb-security arch doesn't precisely encourage you to
implement DTLS 1.0; there's no normative language at all (even in the
non-2119 sense). It makes s factual statement about the history of the
document and about the impact of implementing only DTLS 1.2 and leaves it
up to the implementor what to do with that statement. I agree that the fact
that it bothers to mention it might be read as implying that people should
do DTLS 1.0, but that's not actually in the text. Indeed, I could imagine
this document including both this text *and* a MUST NOT implement DTLS 1.0
(that's actually how one has to interpret the union of
draft-ietf-rtcweb-security-arch and draft-ietf-tls-oldversions-deprecate),
with the understanding that the point of the "might encounter
interoperability issues" is to document the impact of the MUST NOT

With that said, as I mentioned in my earlier response, it was understood
when we adopted this draft that this was kind of a 6119 "MUST (but we know
you won't)" situation. See, for instance. the comments from DKG in the
minutes here:

"DKG: we can afford to publish this without driving numbers down to zero.
Multiple audiences for documents like this, can make sure this is useful
for many audiences. Clear advice for implementers: can't remove entirely,
but here are things you can do. We publish this now to drive adoption, not
wait for adoption to drive"