Re: [TLS] Proposed text for dnsssec chain extension draft

Viktor Dukhovni <> Thu, 26 April 2018 16:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42799126D85 for <>; Thu, 26 Apr 2018 09:06:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0lqv9gslT9D9 for <>; Thu, 26 Apr 2018 09:06:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8113B124205 for <>; Thu, 26 Apr 2018 09:06:47 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id A8BF37A3309 for <>; Thu, 26 Apr 2018 16:06:46 +0000 (UTC) (envelope-from
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Thu, 26 Apr 2018 12:06:45 -0400
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG <>
Message-Id: <>
References: <> <> <> <> <20180426152206.GM25259@localhost> <>
To: TLS WG <>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <>
Subject: Re: [TLS] Proposed text for dnsssec chain extension draft
X-Mailman-Version: 2.1.22
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, 26 Apr 2018 16:06:49 -0000

> On Apr 26, 2018, at 11:41 AM, Eric Rescorla <> wrote:
> This discussion would probably be a lot more productive if you were
> able to have it without accusing other participants of acting in bad
> faith.

[ Well the objections do seem rather hypothetical, and the thing being
  objected to (a 16-bit reserved field) so minimally objectionable, that
  it is   perplexing why it is so important to avoid reaching a compromise
  by   allowing the 2-byte to be added.  Indeed it sure looks like the
  separate document that might define the follow-on extension would
  be strongly opposed in any form by those opposing the reserved 2 bytes,
  but I'd be thrilled to learn of your support in principle for such a
  document, perhaps you'd even be willing to author (or co-author) the
  initial draft? ]

I rather like Paul's point that the lifetime of support for
this extension belongs with this extension.  Adding an extension to
signal ongoing support for another extension rather unnatural.