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

Benjamin Kaduk <> Thu, 10 October 2019 18:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C668C120111; Thu, 10 Oct 2019 11:38:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uOOUv-wiLVw4; Thu, 10 Oct 2019 11:38:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9479E120127; Thu, 10 Oct 2019 11:38:57 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id x9AIcqvT019338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Oct 2019 14:38:54 -0400
Date: Thu, 10 Oct 2019 11:38:52 -0700
From: Benjamin Kaduk <>
To: Rob Sayre <>
Cc: "" <>, "" <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.12.1 (2019-06-15)
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: Thu, 10 Oct 2019 18:39:00 -0000

On Fri, Oct 11, 2019 at 12:45:11AM +0700, Rob Sayre wrote:
> On Thu, Oct 10, 2019 at 11:17 PM Benjamin Kaduk <> wrote:
> > The decision about
> > whether to make changes to the technical content thus lies with the
> > sponsoring AD for that document.
> >
> >
> I don't think that is true. Here is one comment from the document shepherd:

I don't think the cited message supports your claim (instead, it's just
commenting on whether changing the text would have any value independently
of the mechanics for doing so).

> This one of those situations where the IETF rules are deliberately
> ambiguous (I know most of the rules...).

I'm the AD for the TLS WG, and am charged with enforcing the rules.  If you
tell me a rule that I'm not enforcing or am misinterpreting, I'm happy to
adjust accordingly, but in the absence of such concrete details, I'm going
to trust my knowledge of the rules more than yours.

> > I disagree that draft-ietf-tls-oldversions-deprecate needs to update all
> > consumers of DTLS 1.0/1.2, at least for the reason you give.  Those
> > documents properly refer to RFC 6347 (or 4347), and it is that RFC that we
> > are updating now.  We do not directly change those consuming documents'
> > needs, but rather do so indirectly.
> >
> That is not what the draft does. For example, it updates RFC 4823, "FTP
> Transport for Secure Peer-to-Peer Business Data Interchange over the
> Internet".

"for the reason you give" being the operative phrase.

> Have you read the draft?

Not recently; as noted upthread, it's in my queue of "publication
requested" documents accumulated backlog, but I have to do an AD evaluation
before it goes to IETF LC.

> > from the IETF perspective
> > it's approved and done, and the barrier to making any further substantive
> > changes is extremely high.
> >
> Nope, it can get changed. And it can get updated too. It's just a text
> file, and the rules are fluid. :)

I did not say it was impossible, just that there is a very high barrier and
in my assessment the value does not justify the cost of changing it.  But
as I've said repeatedly, I'm not the AD whose judgment matters, and I am
confused at why you're continuing to engage on the topic in this forum.