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

[Viktor Dukhovni <[e-mail]>]

> On Apr 10, 2018, at 9:48 AM, Shumon Huque <[e-mail]> 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 <[e-mail]>
  Date: Thu, 5 Apr 2018 12:07:57 +1000
  To: TLS WG <[e-mail]>
  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.

-- 
	Viktor.