<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 Mon, Jun 28, 2021 at 7:06 PM Donald Eastlake <<a href="mailto:d3e3e3@gmail.com">d3e3e3@gmail.com</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 Mon, Jun 28, 2021 at 3:07 PM Phillip Hallam-Baker<br>
<<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>> wrote:<br>
> On Mon, Jun 28, 2021 at 4:19 AM Bill Woodcock <<a href="mailto:woody@pch.net" target="_blank">woody@pch.net</a>> wrote:<br>
>> > On Jun 26, 2021, at 8:17 PM, Phillip Hallam-Baker <<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>> wrote:<br>
>> > 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<br>
>><br>
>> 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.<br>
><br>
> 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<br>
<br>
DNSSEC and TSIG are orthogonal. DNSSEC authenticates DNS data, or the<br>
non-existence of that data, based on the authority of the zone owner.<br>
TSIG authenticates DNS messages based on the authority of a DNS server<br>
you have chosen to trust (usually via a shared secret key). They work<br>
quite well together. If you don't want to do DNSSEC yourself and trust<br>
some server to do it for you, just negotiate TSIG to securely delegate<br>
the DNSSEC processing to that server. I don't see how DNSSEC "block"s<br>
TSIG.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">We should have done both. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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)</div><br></div><div><br></div><div> </div></div></div>