[dns-operations] DNSSEC deployment incentives

[Phillip Hallam-Baker]

On Tue, Jun 18, 2019 at 9:33 PM Viktor Dukhovni <ietf-dane at dukhovni.org>
wrote:

> On Tue, Jun 18, 2019 at 08:59:59PM -0400, Phillip Hallam-Baker wrote:
>
> > There is no reason to think that DANE is going to deploy automatically
> > simply by waiting longer. The DNS registrars have no interest in
> supporting
> > the TLSA record using the tools they make available to the vast majority
> of
> > their customers. They won't do that because it will take cash out of
> their
> > pocket.
>
> But Let's Encrypt de-monetized certificate issuance, so now that
> obstacle is moot.
>

It has also eliminated the incentive to deploy DANE for free certs.



> > And BTW: If we count trust roots the way that the EFF did, DNSSEC has a
> > million trust roots (or however many zones are signed) not one. It was an
> > utterly bogus comparison.
>
> This is in turn a false analogy.
>

No, the analogy is exact, The DFN root also constrained the sub-CAs so that
they could not issue an arbitrary certificate. This was pointed out to the
EFF, they chose not to correct.



> There are somewhere between 10-11 and million signed zones, BUT
> they cannot issue certificates for anybody else, just their own
> domain and below.  If we're simply counting trusted keys, then every
> one of the 4+ billion keys in the CT chain is a trusted EE key (for
> its own name).
>

The PKIX spec has an NSA inserted bug which required name constraints to be
marked critical. This caused certificate validation to fail on legacy Apple
browsers. So nobody could use name constraints while they would cause about
1% of Internet browsers to break. We solved this in CABForum following the
EFF mendacity by amending the guidelines to allow deviation from PKIX in
this case.



> The number of *configured* trust-anchors is often just the root
> key, but intramural corporate deployments can and should publish
> internal trust-anchors for their own domains' internal DNS.
>

Every entity should have a single root of trust that it controls itself.
Putting ICANN in charge of the root of roots is unacceptable.

One of the things Melih wanted me to do with the Mesh was to allow that
model of trust management. The capabilities are there in the code but not
implemented as yet since I am no longer with Comodo.



> The trust-model supports delegation with built-in name constraints,
> which is a natural fit for DNS, since that's all the certificates
> are about.  If you don't trust your parent zone, don't register
> there, they can take away your domain and assign it to someone else,
> and whoever that is, can then a cert from a commercial CA.
>

The problem is that you can only have a single source of authority in a
global naming system. And a trust infrastructure requires multiple sources
of authority because different operations require different degrees of
trust. That is why we didn't go with the DNSSEC model back in the 1990s. We
were aware of it when we chose X.509.



> So if we accept your analogy, the commercial CA ecosystem has 50
> (if I correctly recall your number) fully trusted root issuers, and
> then all the parent domains that can reassign your domain trusted
> for just their scope, and then anybody with the right access to BGP
> to hijack your address space...
>

The WebPKI has the CAA and CT systems these days which makes it very
difficult to make an attack without it being visible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190619/e6453bcb/attachment.html>