On Monday, January 19, 2015, George Michaelson <g...@algebras.org> wrote:
> I think its possible people have misunderstood what we said, when we > measured 'do not understand ECDSA' as a problem and presented on it. > Dunno. I think many / most folk got it, at least in the venues I saw it.. > > > > It is a tenable, arguable case, that PRECISELY because the fail mode is > 'unsigned' we can move to ECDSA more easily than any other key transition > under discussion: the fail mode breaks DNSSEC validation by returning to > unsigned state. Not by preventing name resolution. > ... thereby defeating the purpose of having signed the zone. > > its the weaker, unprotected but results returned fail mode. > Yes, is is definitely way better than having it "break" / go bogus, but, depending on what you think you are getting from DNSSEC, still suboptimal. > > If we want small, short tractable signatures in DNS, moving to eCDSA is > easier now than at any other time. We just have to accept we make a lot of > DNSSEC clients stop validating until code updates. > Well, IMO, we need people to *understand* what the impact is, especially for the root key / things up the tree. My personal view is that the benefit of ECC outweighs the cost, but it's not just my domains that get affected. W > > thats how I read it, anyway. > > -G > > On Mon, Jan 19, 2015 at 1:17 PM, Warren Kumari <war...@kumari.net > <javascript:_e(%7B%7D,'cvml','war...@kumari.net');>> wrote: > >> >> >> On Monday, January 19, 2015, Francis Dupont <francis.dup...@fdupont.fr >> <javascript:_e(%7B%7D,'cvml','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 >>> >> >> >> -- >> 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 <javascript:_e(%7B%7D,'cvml','DNSOP@ietf.org');> >> https://www.ietf.org/mailman/listinfo/dnsop >> >> > -- 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
