<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 6, 2017 at 4:25 PM, Mark Andrews <span dir="ltr"><<a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
In message <<a href="mailto:065CE0C6-C59C-4757-A07F-00CAF6B20CD3@rfc1035.com">065CE0C6-C59C-4757-A07F-<wbr>00CAF6B20CD3@rfc1035.com</a>>, Jim Reid writes:<br>
><br>
> > On 6 Mar 2017, at 20:05, Phillip Hallam-Baker <<a href="mailto:phill@hallambaker.com">phill@hallambaker.com</a>><br>
> wrote:<br>
> ><br>
> > I have never ever encountered a situation in which an employee of<br>
> company X has said that 'Y is a show stopper issue for us, we cannot<br>
> deploy unless it is addressed' and company Y has subsequently deployed.<br>
><br>
> You must have been elsewhere during the DNSSEC protocol war 10-12 years<br>
> ago.<br>
><br>
> Back then various employees, managers and board members of several TLD<br>
> registries said they would never deploy DNSSEC unless the IETF found a<br>
> solution to their zone enumeration concerns. This was a showstopper for<br>
> them. ISTR those very words being used at that time too. At least one<br>
> registry went ahead and deployed DNSSEC-bis (zone enumeration included),<br>
> securing their TLD without waiting a further 5 years or so until<br>
> DNSSEC-ter was ready. Theyre still using DNSSEC-bis today.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">​I was Principal Scientist at VeriSign and I know exactly what the situation was.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> However that existence proof is just detail.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">​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.​</div></div><div class="gmail_default" style="font-size:small"><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Its simply absurd for you to assert that if company X says foo is a<br>
> showstopper for us, that automatically makes foo a showstopper for<br>
> company Y. One companys showstopper is by definition another companys gap<br>
> in the market or business opportunity.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">​Absolutely not what I said. I never referred to a company Y. ​ read the damn message.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But in DNSSEC that assertions were we won't sign because ... and<br>
DNSSEC doesn't require that everyone sign<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">​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.</div><br></div><div><div class="gmail_default" style="font-size:small">​Oh and we would have had to change the client-resolver protocol to get them on board anyway. ​</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In reality you can't prevent tlds being enumerated for active<br>
domains.  You look at resolver traffic from many places to build<br>
up a database of active names.  We said that at the time and it is<br>
reality today.<br>
<br>
Now not having a NSEC record for every delegation still helps<br>
somewhat for some TLD.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">​Exactly. ​</div><br></div><div><div class="gmail_default" style="font-size:small">​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.​</div><br></div><div> </div></div></div></div>