[dns-operations] unfounded showstopper assertions
Phillip Hallam-Baker
phill at hallambaker.com
Mon Mar 6 21:54:28 UTC 2017
On Mon, Mar 6, 2017 at 4:25 PM, Mark Andrews <marka at isc.org> wrote:
>
> In message <065CE0C6-C59C-4757-A07F-00CAF6B20CD3 at rfc1035.com>, Jim Reid
> writes:
> >
> > > On 6 Mar 2017, at 20:05, Phillip Hallam-Baker <phill at hallambaker.com>
> > wrote:
> > >
> > > I have never ever encountered a situation in which an employee of
> > company X has said that 'Y is a show stopper issue for us, we cannot
> > deploy unless it is addressed' and company Y has subsequently deployed.
> >
> > You must have been elsewhere during the DNSSEC protocol war 10-12 years
> > ago.
> >
> > Back then various employees, managers and board members of several TLD
> > registries said they would never deploy DNSSEC unless the IETF found a
> > solution to their zone enumeration concerns. This was a showstopper for
> > them. ISTR those very words being used at that time too. At least one
> > registry went ahead and deployed DNSSEC-bis (zone enumeration included),
> > securing their TLD without waiting a further 5 years or so until
> > DNSSEC-ter was ready. Theyre still using DNSSEC-bis today.
>
I was Principal Scientist at VeriSign and I know exactly what the
situation was.
Deployment of DNSSEC was originally planned as part of the ATLAS
deployment. The code was written and would have been pushed out. Absolutely
the only reason it did not was that signing the .com zone using the
technology then available would take far too long and would increase the
data volumes to the point where it was not possible to support the existing
code on a 32 bit machine.
ICANN was not an issue, nor was the EU privacy directive. Had zone
enumeration been raised as an issue, the NSEC proposal would have addressed
it. Note that even if .com had rolled out on ATLAS with an NSEC spec that
was unacceptable to the EU zones, this would have been easy to correct
later on.
It was only after it was realized that DNSSEC was not going to be deployed
in .com without a revision to NXT that NSEC3 was passed and by then ICANN
had woken up and the cost of any change was vastly higher. Also ATLAS was
running and it is much harder to sneak in a feature like DNSSEC after the
fact.
> However that existence proof is just detail.
>
It is an absurd invention. VeriSign said NXT was an absolute show stopper.
VeriSign did not deploy till NSEC3 allowed insecure zones to be skipped.
That is the fact and it is absolutely consistent with my assertion.
> > Its simply absurd for you to assert that if company X says foo is a
> > showstopper for us, that automatically makes foo a showstopper for
> > company Y. One companys showstopper is by definition another companys gap
> > in the market or business opportunity.
>
Absolutely not what I said. I never referred to a company Y. read the
damn message.
> But in DNSSEC that assertions were we won't sign because ... and
> DNSSEC doesn't require that everyone sign
>
Well it was a much bigger ask than mere deployment because the idea was
that VeriSign might persuade Microsoft to deploy DNSSEC code in the
platform. Only that never happened because Microsoft was increasingly less
willing to play the same industry leadership role it played in the 1990s.
Oh and we would have had to change the client-resolver protocol to get
them on board anyway.
In reality you can't prevent tlds being enumerated for active
> domains. You look at resolver traffic from many places to build
> up a database of active names. We said that at the time and it is
> reality today.
>
> Now not having a NSEC record for every delegation still helps
> somewhat for some TLD.
>
Exactly.
Only at the time of the ATLAS rollout it was a go/nogo show stopper. Today
memory is cheap enough and 64 bit CPUs are standard and is arguably does
not matter but at the time it mattered a lot.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20170306/4eb706db/attachment.html>
More information about the dns-operations
mailing list