<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 18, 2019 at 9:33 PM Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org">ietf-dane@dukhovni.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jun 18, 2019 at 08:59:59PM -0400, Phillip Hallam-Baker wrote:<br>
<br>
> There is no reason to think that DANE is going to deploy automatically<br>
> simply by waiting longer. The DNS registrars have no interest in supporting<br>
> the TLSA record using the tools they make available to the vast majority of<br>
> their customers. They won't do that because it will take cash out of their<br>
> pocket.<br>
<br>
But Let's Encrypt de-monetized certificate issuance, so now that<br>
obstacle is moot.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">It has also eliminated the incentive to deploy DANE for free certs.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> And BTW: If we count trust roots the way that the EFF did, DNSSEC has a<br>
> million trust roots (or however many zones are signed) not one. It was an<br>
> utterly bogus comparison.<br>
<br>
This is in turn a false analogy.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
There are somewhere between 10-11 and million signed zones, BUT<br>
they cannot issue certificates for anybody else, just their own<br>
domain and below.  If we're simply counting trusted keys, then every<br>
one of the 4+ billion keys in the CT chain is a trusted EE key (for<br>
its own name).<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The number of *configured* trust-anchors is often just the root<br>
key, but intramural corporate deployments can and should publish<br>
internal trust-anchors for their own domains' internal DNS.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Every entity should have a single root of trust that it controls itself. Putting ICANN in charge of the root of roots is unacceptable.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The trust-model supports delegation with built-in name constraints,<br>
which is a natural fit for DNS, since that's all the certificates<br>
are about.  If you don't trust your parent zone, don't register<br>
there, they can take away your domain and assign it to someone else,<br>
and whoever that is, can then a cert from a commercial CA.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So if we accept your analogy, the commercial CA ecosystem has 50<br>
(if I correctly recall your number) fully trusted root issuers, and<br>
then all the parent domains that can reassign your domain trusted<br>
for just their scope, and then anybody with the right access to BGP<br>
to hijack your address space...<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">The WebPKI has the CAA and CT systems these days which makes it very difficult to make an attack without it being visible.</div><div class="gmail_default" style="font-size:small"></div></div></div>