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

[Shumon Huque <[e-mail]>]

On Wed, Apr 4, 2018 at 1:50 PM, Joseph Salowey <[e-mail]> 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
capabilities.

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
  header).

-- 
Shumon Huque