[dns-operations] DNSSEC deployment incentives

[Phillip Hallam-Baker]

On Tue, Jun 18, 2019 at 7:04 PM Paul Vixie <paul at redbarn.org> wrote:

> On Tuesday, 18 June 2019 20:48:16 UTC John Levine wrote:
> ...
> > >>> Why not get some TLSA records going for that server too Bill, if
> you're
> > >>> using TLS?
> >
> > Now we get to ponder which is more broken, DNSSEC (and registrar
> > account compromises), or the world of CAs.
>
> in that case, there's no useful debate remaining. one trust anchor
> operated by
> a public charity with high transparency is better than 2000+ trust anchors
> operated mostly by government intelligence shell companies without
> transparency.
>

Complete bullshit. The EFF study was a pile of poo. They knew they were
peddling a falsehood but t=as with Al Gore invented the Internet, once a
lie is spread it is impossible to unspread it.

No, there are 50 commercial CAs. There have never been 2000 roots of trust,
that was the result of the EFF not knowing how PKIX works and refusing to
make a public correction after the error was pointed out.

Basically, the German educational CA created a separate sub-CA for every
university they supported meaning that there were 600 sub CAs chained to
their root. Rather than ask why that was the case, they published the
report. And why not publish a complete lie when it supports the case you
want to make?

Oh because this is a trust business and maybe telling lies was not the best
way to start LetsEncrypt.





> i don't like trust anchors, or internet governance as practiced in the
> modern
> era, or one-egg one-basket designs. however, this time the alternative has
> proved itself to be amazingly worse than the worst-case scenario of a
> single
> trust anchor.
>
> we must kill off the world's dependency on X.509 CA cert repositories,
> a-s-a-
> p. we had a situation so terrifyingly awful that lets-encrypt was able to
> make
> it even worse, regardless of intentions. let's move on.
>
> --
> Paul
>
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190618/badaa799/attachment.html>