On Fri, Mar 28, 2014 at 9:50 AM, Joe Abley <jab...@hopcount.ca> wrote:
> > On 28 Mar 2014, at 9:06, Phillip Hallam-Baker <hal...@gmail.com> wrote: > > > Therefore ICANN needs to sign the root zone with 2048 before we consider > it signed. End of story. > > Small point of clarity: the only key that ICANN maintains is the 2048 bit > KSK, and the only signatures ICANN makes with it are over the DNSKEY RRSet. > The 1024 bit ZSKs and signatures made by those keys are handled exclusively > by the Root Zone Maintainer (Verisign). > > It's not clear to me that any changes would be required at ICANN to > accommodate 2048 bit ZSKs. As I recall, every KSR that is submitted for > processing at a ceremony is carefully tested in dry runs before the date > anyway, so even the existing QA could continue unchanged. > VeriSign is acting on ICANN's instructions. Burt Kaliski knows how to set an RSA key length. If they take the decision the change will be made. The root is signed using the ZSK which is 1024 bit. Ergo it is fair to say that the root signatures are defective. This is not an issue of hindsight. We have been phasing out 1024 bit certs in the WebPKI since long before the Snowden disclosure. And unlike DNSSEC we had the excuse of a very large legacy deployment to contend with. The RSA768 break was the signal that RSA1024 was no longer to be considered safe. When RSA 1536 is broken it will be time to go to the ECC schemes. The reason that I can't see any ongoing risk from RSA1024 after we complete the transition is that I expect sensible applications will (1) simply discard RSA1024 bit signatures as invalid and (2) discard any signature that purports to have been made before the time that the code was compiled. I suggest that we adopt the following strategy: 1) Have some form of formal communication from the IETF to ICANN notifying them that the RSA1024 signing is insecure. 2) Consider ways to avoid having future security requirements being constantly compromised by the limit of one 1500 byte response packet on UDP. A more research oriented approach is that sites deploying DNSSEC create or have issued an X.509v3 cert for their KSK and publish that in their zone. That can then be used as a local trust anchor within the local network. It can also be enrolled in Certificate Transparency. One conclusion that should be drawn from the RSA1024 fiasco is that ICANN is not in the business of cryptography and the current institutional relationships are unsatisfactory. VeriSign is more than competent to make the right decision. But the responsibility and decision power is split so they don't actually have decision making power, nor does the IETF. -- Website: http://hallambaker.com/
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
