Re: dnscurve -- new or did I just miss this?
Francis Dupont
so there is little motivation to moving to elliptic curves.
=> I disagree:
- ECs are faster than RSA and give smaller keys and signatures
- ECs are based on a different mechanism than RSA, it is important
to provide a choice between two basic mechanisms in case one of
them is discovered far too weak (note this applies too to a EC
only solution :-)
So IMHO it should be good to investigate about an ECDSA DNSSEC option.
Regards
PS: cryptographers I know promote the use of ECs...
--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Stephane Bortzmeyer
Blacka, David <dav...@verisign.com> wrote
a message of 27 lines which said:
> There isn't one that made it through last call, but there is a proposed
> definition. See:
> http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-ecc-key/
Warning, we are deriving into a general discussion on EC cryptography
and this thread, IMHO, should stay focused on DNScurve.
bert hubert
> > definition. See:
> > http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-ecc-key/
>
> Warning, we are deriving into a general discussion on EC cryptography
> and this thread, IMHO, should stay focused on DNScurve.
Ah yes, very good. Ok - about there being no trust anchors, I don't think
this is explicit in the design. They just haven't been mentioned yet, but
I'm pretty sure they could be added out of band - for people who want to be
really sure.
Bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
Francis Dupont
> - ECs are based on a different mechanism than RSA, it is important
> to provide a choice between two basic mechanisms in case one of
> them is discovered far too weak (note this applies too to a EC
> only solution :-)
This I disagree with.
Although the elliptic curve discrete log problem (and the discrete log
problem in general) are separate from the factoring problem, every
breakthrough in one almost invariably produces a breakthrough in the
other.
=> this is your opinion but we have no proof one way or the other.
I agree it should be better to have the other mechanism very different
but as far as I know there is no solid proposal today...
Additionaly, there was a big discussion of this very problem at the
AES candidate meeting in the "choose 1 algorithm or 2" discussion. In
general, the crptographer's consensus is that only a single algorithm
should be chosen, as actually specifying two opens up more
vulnerabilities than a fallback provision provides.
=> the situation is not the same in PKI-like system where a second
mechanism is desirable. This role was taken by DSA but it seems nobody
uses DSA in DNSSEC and X.509 PKIs go from DSA to EC. My idea is if
this is good for X.509 PKI there is no reason to stay far behind.
Regards
PS: about DNSSEC today we are no more a choice: it is simply too late:
if there was a good alternative to DNSSEC its time was some years ago...
Paul Hoffman
>=> the situation is not the same in PKI-like system where a second
>mechanism is desirable. This role was taken by DSA but it seems nobody
>uses DSA in DNSSEC and X.509 PKIs go from DSA to EC.
This makes no sense on a number of fronts:
- The adoption of EC in PKIX-based applications is still minuscule
- You can't go "from DSA to EC" because the EC use of PKIX is for
ECDSA. (ECDH is even more minuscule, by far, than ECDSA.)
> My idea is if
>this is good for X.509 PKI there is no reason to stay far behind.
We agree on that. There are certainly markets that want EC for a
variety of reasons.
--Paul Hoffman, Director
--VPN Consortium