On Monday, January 19, 2015, Francis Dupont <francis.dup...@fdupont.fr> wrote:
> In your previous mail you wrote: > > > Currently a number of validators don't do ECC, because of the openssl > > library from the distribution they are using doesn't include support. > > This makes ECC an unsupported algorithm, and so it "fails open" (See > > RFC4035, Section 5.2, around "If the validator does not support any of > > the algorithms"...). Geoff also has a good blog post > > (http://labs.apnic.net/blabs/?p=544) and presentations at various > places > > (e.g: https://ripe69.ripe.net/presentations/135-18-2014-11-01-ecc.pptx > ). > > => This very unfortunate fact is IMHO the major (and perhaps only) issue > to solve before deploying ECDSA (and solve the RSA/SHA-1 vs RSA/SHA-2 > question). Unfortunately not the only - we also need the registrars to accept ECDSA. But yes, this is annoying- rolling the DNSSEC root key to ECDSA would be very cool, as we could then fit 2 signatures well within the IPv6 MTU. Oh, as was pointed out earlier, Google Public DNS does ECDSA. W > > > I suggest that folk whose ssl libraries don't support ECC should > > figure out why (see http://tools.ietf.org/html/rfc6090 and also > > Geoff's blog post for some background) and then recompile with > > support[0]. > > => I can't say more. > > Thanks > > francis.dup...@fdupont.fr <javascript:;> > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
