[Cryptography] Doing DNS properly Re: Apple's iCloud+ "VPN"

Phillip Hallam-Baker phill at hallambaker.com
Tue Jun 29 00:50:23 EDT 2021


On Mon, Jun 28, 2021 at 7:06 PM Donald Eastlake <d3e3e3 at gmail.com> wrote:

> On Mon, Jun 28, 2021 at 3:07 PM Phillip Hallam-Baker
> <phill at hallambaker.com> wrote:
> > On Mon, Jun 28, 2021 at 4:19 AM Bill Woodcock <woody at pch.net> wrote:
> >> > On Jun 26, 2021, at 8:17 PM, Phillip Hallam-Baker <
> phill at hallambaker.com> wrote:
> >> > Attempts to revise the DNS system have invariably fallen foul of
> second system syndrome. DNSSEC is a half baked attempt to turn the DNS into
> a PKI that has since been adopted as a solution to DNS insecurity
> >>
> >> There’s a lot wrapped up in there, but I generally agree.  DNSSEC is
> over-complicated and over-fragile, too arcane, and needlessly reinvents the
> wheel.  Yet it is better than nothing, and it’s what we wound up with.
> Notably, I’m not an apologist with respect to RPKI, so I don’t just roll
> over and accept whatever half-assed thing makes it through the
> standardization compromise process.  I do very much think DNSSEC is better
> than nothing, and have put my money where my mouth is for more than twenty
> years.
> >
> > My problem is that DNSSEC was rolled out as the solution to the Kaminsky
> vulnerability in place of fixing the DNS protocol to add TSIG to every
> communication. A solution that has a major deployment footprint should not
> block simpler solutions that could have served everyone
>
> DNSSEC and TSIG are orthogonal. DNSSEC authenticates DNS data, or the
> non-existence of that data, based on the authority of the zone owner.
> TSIG authenticates DNS messages based on the authority of a DNS server
> you have chosen to trust (usually via a shared secret key). They work
> quite well together. If you don't want to do DNSSEC yourself and trust
> some server to do it for you, just negotiate TSIG to securely delegate
> the DNSSEC processing to that server. I don't see how DNSSEC "block"s
> TSIG.
>

We should have done both.

The Kaminsky bug was discovered while we were still arguing over NSEC4
without which deployment of DNSSEC could not possibly happen. IETF was told
in 2001 that unless the NXT record was changed, DNSSEC could not be
deployed in .COM. IETF refused and as a direct result, the DNSSEC
deployment planned to roll out as part of ATLAS deployment in 2002 didn't
start happening until 2010.

TSIG is fine but doesn't work as an authentication scheme because there is
no key agreement mechanism. We could have easily done it right but the
paranoia surrounding rollout of the fix to Kaminsky meant none of the
people in the room was a crypto protocol person. So instead we got the weak
security from rotating the source IP port as pro tem. We had the
opportunity to do a proper fix, everyone who was managing a DNS server
codebase was in the room except for DJB, the only guy who got it right
first time round (and told everyone)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210629/4aa92d9b/attachment.htm>


More information about the cryptography mailing list