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

Shumon Huque <> Tue, 10 April 2018 13:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 38B65127735 for <>; Tue, 10 Apr 2018 06:48:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aVfqdVj3pb-f for <>; Tue, 10 Apr 2018 06:48:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D62B212D7E2 for <>; Tue, 10 Apr 2018 06:48:25 -0700 (PDT)
Received: by with SMTP id q80so13707448ioi.13 for <>; Tue, 10 Apr 2018 06:48:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RE5WFr7VeS3kNC0TC7uf3S2d/KKCK3Xu/xDtv8Z3B9Q=; b=dfYTy0lKRoSscOOkCaJG214GmoGJDtuKz8Opw4MLwaEDDbUvZ2JkDwkPFnNqEM2QX2 Ty2x4c3M6R/Pmp5McVD1En491iB6HPcS/X+7TJWIfIEfuWfjO5U1dCKAWkZNwtBIb5gE eRlEqXuebGM8HG/BDTiGa35otaQui7kRPpFCE+GZlMLXx7hLgA1HXjlgA75WLaG5kOKs kFFZtY8iniZWPiF3hZGTfYzxK+HSm/t8X/Mf3OSJ0hGu+YDTSCov/AEB01BpoeLtGbsk cHuj7cExrSe2deuACTzlWcrg8ruSLl4tzoFgatPIFLE/7Hmq9TdkrVGOwEvuEU2cn5dz SI5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RE5WFr7VeS3kNC0TC7uf3S2d/KKCK3Xu/xDtv8Z3B9Q=; b=FZKnn+py+xlHhpr912oGKqFg2V5MjKuVBtBvme/zl3g3Pjn6nMA1+GxNjIucvq1sVv P14ufN4ncfotGHknofkxdm/+tl+Q2haHpVRYQQ4TcpGl4M8CFq2vSgyrtZm2eL4T/9hp IxpMxPTeFDEN0qQo1NNfKweMeFbGm5sebAlteBR1ard9BUzRchGPM7NIX0EWMJ9tSln3 M/m3LL8j7fhduV+5FlBjo1RsPekIhoZ3/9uokF2c209zcNr1uOmq0aW9JG6nS2SWXY/z FNxcHvMihZMyAVf8HyWOxbneqgXOmoVHVtU5plvuSOTA8F6Urh23ri0j++HPWorteXE5 /ViQ==
X-Gm-Message-State: ALQs6tBtXwDwkqEAXrr4oFgcJGICwICbXCyvp1oDMUlGLUtm2NVokff+ FpdkbX6sfQg0JqXnw3LlRjLAxtFEv+ziF4obvwQ=
X-Google-Smtp-Source: AIpwx49iWSPX+bsEhRZULD1JTPhv6rwWhKRmYKvqS/m5GwBVOK+3Jxq0XVU79PpI4b1rs3l79SQsx+ujcl/pdT1N6z0=
X-Received: by with SMTP id l95mr524733iod.179.1523368105031; Tue, 10 Apr 2018 06:48:25 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 10 Apr 2018 06:48:24 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Shumon Huque <>
Date: Tue, 10 Apr 2018 09:48:24 -0400
Message-ID: <>
To: Joseph Salowey <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="001a113f3a7ec344f105697ec688"
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 13:48:47 -0000

On Wed, Apr 4, 2018 at 1:50 PM, Joseph Salowey <> wrote:

> Hi Folks,
> Some objections were raised late during the review of
> the draft-ietf-tls-dnssec-chain-extension. The question before the
> working group is either to publish the document as is or to bring the
> document back into the working group to address the following issues:
> - Recommendation of adding denial of existence proofs in the chain
> provided by the extension
> - Adding signaling to require the use of this extension for a period of
> time (Pinning with TTL)
> This is a consensus call on how to progress this document.  Please answer
> the following questions:
> 1) Do you support publication of the document as is, leaving these two
> issues to potentially be addressed in follow-up work?

Yes. I support the publication of the document as is.

and would like to explain my position a bit.

I'm very sympathetic to Viktor's desire to enhance this protocol
to provide downgrade resistance against PKIX attacks, and I
generally would share that desire too.

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.

I also feel that the amount of time it has taken to finish up
this draft has significantly hurt its deployment chances. In the
early days of this draft there was (in my view) a window of opportunity
where some browsers had actual interest in implementing this spec.
But in the intervening time, there have been enough bandaids (CT
and strengthed CAB forum requirements) applied to the WebPKI that
to many people in the web community, the risk of bad actors has been
sufficiently mitigated. But to the extent that there are still some
folks interested in this proposal, I see no benefit in proposing an
additional feature that they've stated doesn't work for them, or
that they will not use.

Another important facet of this debate that so far has not surfaced
on recent mailing list discussions is an assessment of the relative
benefits of webpki versus dane, and the recognition that there are
strongly divergent views on this topic. In the early days of this
draft, a number of web folks made it quite clear to me that this
protocol can't be used to compel the use of DANE, and that the browser
gets to decide what to use (and so dane-to-pkix downgrade attacks were
not a concern for them). The large majority of DNSSEC proponents I
know (and I'll state upfront that I'm one of them) clearly feel that
DANE is superior to webpki, and that it's logical that DANE should be
used to address webpki security issues. But this view is not shared by
many others, most particularly in the web community. I've been
involved in many lengthy debates on this topic, and the arguments
against DANE usually boil down to: (1) widespread use 1024-bit RSA
as the weak link in the majority of DNSSEC chains, (2) mistrust of
registrars and their potential security failings, (3) mistrust of
registries and/or other ancestor zones that could mount targeted
attacks that could only be detected by a DNSSEC key transparency
system, ala CT. These are legitimate arguments, and until we have
better answers to them, I'm not inclined to aggressively push DANE,
and position it as unconditionally superior, on communities that have
expressed these concerns.

Viktor has asserted that no-one will be motivated to deploy DANE
without protection against PKIX downgrade, because there is no
compelling enough additional gain of security. He may be right or
wrong, but I've already heard several web folks disagree with him.
And furthermore, they've expressed what I think are legitimate
concerns about the fragility of the pinning proposal. Yes, I agree
that it's not as bad as HPKP, but I also agree that there are more
risks and failure possibilities than HSTS.

As for other applications, we've already heard from a number of
folks in the DNS over TLS camp that the draft works for them in
the current form. Most DNS over TLS clients are expected to have
explicit configuration of their resolver addresses and DANE

Some possible ways forward I see for folks wanting to develop a version
of this spec with PKIX downgrade resistant capabilities (I've already
stated earlier, that I would be happy to participate in such efforts):

* Develop a new spec, with a new codepoint, and let the specs compete
  for adoption.
* Develop a -bis document - if we manage to get WG consensus on the
  approach at a later date.
* Do something outside the protocol, and specific to applications
  that want to include mechanisms to mandate DANE usage (like a HTTP

Shumon Huque