Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

Viktor Dukhovni <> Tue, 10 April 2018 14:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E39012DA51 for <>; Tue, 10 Apr 2018 07:20:06 -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 6wpg7hcda_kv for <>; Tue, 10 Apr 2018 07:20:04 -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 271D4129BBF for <>; Tue, 10 Apr 2018 07:20:04 -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 16CAC7A3309 for <>; Tue, 10 Apr 2018 14:20:02 +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: Tue, 10 Apr 2018 10:20:01 -0400
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG <>
Message-Id: <>
References: <> <>
To: TLS WG <>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <>
Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
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: Tue, 10 Apr 2018 14:20:08 -0000

> On Apr 10, 2018, at 9:48 AM, Shumon Huque <> wrote:
> But I would also like to publish a document that has the solid
> consensus of the community that is one of key potential target
> consumers of this draft (web browsers and servers). So I'm giving
> more weight to their views and preferences. To date, the only
> people from that community that have spoken up have expressed
> strong opposition to Viktor's proposed enhancement.

There'll be negligible adoption of this draft as-is by Web Server
operators on the public Internet.  It offers them all pain and no
gain.  ZERO additional security over and above what they get with
Let's Encrypt, only additional operational complexity and a new
way to fail when the client supports DANE and the TLSA records
are stale.

Outside a few bilateral or intramural arrangements for mandatory
DANE by clients when accessing specific destination servers, anyone
deploying the present specification for the Web, is a masochist, or
simply ignorant of what they're getting.

What your response omits is any sort of cost/benefit analysis of
the applicability of the present proposal to the Web. To be a
proponent of adoption, you need to propose a specification that
delivers tangible benefits at [plausibly] acceptable cost.

No amount of wishful thinking or expedited publication will lead
to meaningful adoption of a technology that is all cost and no
benefit.  If there's a flaw in my cost/benefit analysis posted
earlier in this thread, please post a correction.

  From: Martin Thomson <>
  Date: Thu, 5 Apr 2018 12:07:57 +1000
  To: TLS WG <>
  Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

  [skepticism re pinning, addressed in follow-ups]
  Your cost benefit analysis seems about right though.

To Willem's point, moving the TTL negotiation out of the TLS
extension into HTTP STS metadata means that each application
protocol (IMAP, JMAP, POP, SMTP submission, ...) that would
employ this specification to address the "last mile" problems
with DNSSEC at mobile client systems, would need to be extended
with a similar protocol extension.  That's rather a lot of
duplicate work (and a lot more delay) for something that can
be done just once and promptly in this specification.