A Deep Dive on the Recent Widespread DNS Hijacking

Tue Feb 26 15:08:28 UTC 2019

On Tue, Feb 26, 2019 at 6:25 AM David Conrad <drc at virtualized.org> wrote:

> On Feb 26, 2019, at 2:35 PM, Ca By <cb.list6 at gmail.com> wrote:
>
> On Tue, Feb 26, 2019 at 1:58 AM Bill Woodcock <woody at pch.net> wrote:
>
>> > On Feb 24, 2019, at 10:03 PM, Hank Nussbacher <hank at efes.iucc.ac.il>
>> wrote:
>> > Did you have a CAA record defined and if not, why not?
>>
>> It’s something we’d been planning to do but, ironically, we’d been in the
>> process of switching to Let’s Encrypt, and they were one of the two CAs
>> whose process vulnerabilities the attackers were exploiting.  So, in this
>> particular case, it wouldn’t have helped.
>>
>> I guess the combination of CAA with a very expensive, or very manual, CA,
>> might be an improvement.  But it’s still a band-aid on a bankrupt system.
>>
>> We need to get switched over to DANE as quickly as possible, and stop
>> wasting effort trying to keep the CA system alive with ever-hackier
>> band-aids.
>>
>>                                 -Bill
>
>
> DNS guy says the solution for insecure DNS is... wait for it.... more DNS
> ...
>
>
> Well, no. "DNS guy” (Bill’s a bit more than that, of course) says the
> solution for a fundamentally broken trust model is a different system to
> derive trust.
>
> Or do you think Let’s Encrypt/Comodo increase trust?
>

The trust issue has not yet been solved on the internet.

Swapping the DNS cabal for the CA cabal is not an improvement. Right?  They
are really the same arbitraging rent-seekers, just different layers.

Using DANE to verify multiple layers is interesting, but the web folks
aren’t playing so it won’t go anywhere. Right?  Google, Wechat, FB, msft,
and Apple aren’t coming along.

Since you mentioned Let’s Encrypt, they have reduced plaint text, which is
great. But trust is a harder issue.

For example, Symantec has lost trust. But only after repeated bad actions.

> Regards,
> -drc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190226/1b85fc62/attachment.html>