Subject: [dnsext] about ECDSA

From: Francis Dupont <[email-masked]>
Date: Fri, 06 Apr 2012 17:09:42 +0200

I am refreshing the ECDSA experimental support in bind9 so
I have some random comments:

 - my Fedora 16 compiles OpenSSL with no Elliptic Curve support (and
  of course no ECDSA). If someone wants to put some pressure to get
  this fixed, I'll join!

 - in http://www.iana.org/assignments/ds-rr-types/ds-rr-types.xml
  SHA-384 is OPTIONAL. I believed the idea was to use it with the new
  ECDSA keys, so this will have to be fixed in the long term. BTW how?

 - I still have a question about the 256/384 pair: are they
  supposed to be handled as two different algos (as RSASHA1 and
  RSASHA256, or RSASHA256 and RSASHA512) or as the same algo
  with two different "strengths"? Note at the beginning (i.e.,
  when I asked this many months ago) it was only a concern for
  the signer but according to a recent discussion it is concern
  for resolvers too.

 - I have the performance figures with the last OpenSSL (1.0.1)
  and its new assembly support (aka enable-ec_nistp_64_gcc_128),
  unfortunately not available for P384 (can't see why)?
  ECDSA is really faster on signing and the verifying is still
  reasonable, so Paul's prediction about EC support quality
  was correct.

Regards

[email-masked]

PS: I am not the right person to ask for ECDSA support in
the next distribs (I don't say you shouldn't ask).
PPS: it should be good to get the examples with a date in
the future.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 6 Apr 2012 08:20:57 -0700

>  of course no ECDSA). If someone wants to put some pressure to get

This is a compile-time option for OpenSSL. If the version of OpenSSL that comes with Fedora 16 doesn't have the option, you can download a fresh version of OpenSSL and build it locally.

>  ECDSA keys, so this will have to be fixed in the long term. BTW how?

Recycling of political discussion; deferred.

>  the signer but according to a recent discussion it is concern

They are different algorithms with different strengths, so your either/or question doesn't make sense. Similarly, each of the defined SHA-2 variants are also different algorithms and each has a different strength.

>  reasonable, so Paul's prediction about EC support quality

Good to hear.

> the next distribs (I don't say you shouldn't ask).

Diddling with OpenSSL in the various Linux distros may not be such a good idea...

> PPS: it should be good to get the examples with a date in

Too late. :-)

--Paul Hoffman

---

From: Francis Dupont <[email-masked]>
Date: Fri, 06 Apr 2012 20:23:49 +0200

In your previous mail you wrote:

>  This is a compile-time option for OpenSSL.

=> in fact a configure-time option: after this unexpected (:-) test of
the ECDSA support detection, I looked at the .spec file: OpenSSL was
configured with 'no-ec no-ecdh no-ecdsa'...

> If the version of OpenSSL that comes with Fedora 16 doesn't have the
> option, you can download a fresh version of OpenSSL and build it
> locally.

=> I did this and took the opportunity to try the new 1.0.1 version.

>  They are different algorithms with different strengths, so your
>  either/or question doesn't make sense. Similarly, each of the defined
>  SHA-2 variants are also different algorithms and each has a different
>  strength.

=> I'll rephrase the question: does it make sense to use
ECDSAP256SHA256 for ZSKs and ECDSAP384SHA384 for the KSK?

>  > the next distribs (I don't say you shouldn't ask).

=> oops, I should have added "bind9" here.

Thanks

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 10 Apr 2012 15:50:09 +0200

Hi Francis,

On 04/06/2012 08:23 PM, Francis Dupont wrote:
>>> RSASHA256, or RSASHA256 and RSASHA512) or as the same algo with
>>> two different "strengths"? Note at the beginning (i.e., when I
>>> asked this many months ago) it was only a concern for the
>>> signer but according to a recent discussion it is concern for
>>> resolvers too.

The first not the latter, like RSASHA1 and RSASHA256, they are
different algorithms.  Use the same algorithm for your ZSK and KSK
(but apply different policy).

>> either/or question doesn't make sense. Similarly, each of the
>> defined SHA-2 variants are also different algorithms and each has
>> a different strength.
> 

No, that is dnssec-bogus.  The ECDSAP384SHA384 for KSK but does not
sign the zone is a signing-error.  You must sign the entire zone with
that algorithm, if you use it.  The algorithm-support is signalled
per-algorithm in DS and DNSKEY records, not for a range or suite of
algorithms.

Best regards,
   Wouter

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 10 Apr 2012 08:25:01 -0700

>>>>> On Fri, 06 Apr 2012 20:23:49 +0200, Francis Dupont <[email-masked]> said:

>> This is a compile-time option for OpenSSL.

FD> => in fact a configure-time option: after this unexpected (:-) test of
FD> the ECDSA support detection, I looked at the .spec file: OpenSSL was
FD> configured with 'no-ec no-ecdh no-ecdsa'...

It's worse than that: they've also removed the code from their compile.
So even if you pull the spec and rebuild with their package, you still
need to use an original (unmodified) upstream source tar-ball.

But the good news is that it's still pretty easy.
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 11 Apr 2012 12:57:12 +0200

>  (but apply different policy).

=> note my question is really about the application of the word
"same" to ECDSAP256SHA256 / ECDSAP384SHA384 (a priori if they
have different code points and names they are not the "same",
now RSA has a degree of freedom which is not present in ECDSA).

>  per-algorithm in DS and DNSKEY records, not for a range or suite of

=> I agree but I want to be sure it is the intented thing.
If there is no opposed opinion in the list I follow you.

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Wed, 11 Apr 2012 13:45:05 +0200

>  But the good news is that it's still pretty easy.

=> as far as I can understand from the Fedora mailing-lists, the reason
is patents on EC technology...

Regards

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 11 Apr 2012 09:15:44 -0700

>>>>> On Wed, 11 Apr 2012 13:45:05 +0200, Francis Dupont <[email-masked]> said:

FD> => as far as I can understand from the Fedora mailing-lists, the reason
FD> is patents on EC technology...

Yep.  They do it to a number of packages.  [ref: mp3 decoding]
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Michael StJohns <[email-masked]>
Date: Wed, 11 Apr 2012 12:22:00 -0400

To be specific, it's not because of the patents, but because of the fear the patents might apply to the code, a fear not shared by OpenSSL for the original code, by BouncyCastle for its java and C# providers, and Oracle for the EC code in JDK 1.7. Oh yeah, for NSS from Mozilla.  

Mike

Sent from my iPad

On Apr 11, 2012, at 7:45, Francis Dupont <[email-masked]> wrote:

> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 12 Apr 2012 09:17:46 -0400

> If there is no opposed opinion in the list I follow you.

Think of the two ECDSA allocations as two DIFFERENT algorithms,
if you elect to use KSK and ZSK split (which I do not think not always 
needed) ECDSA does not allow you the flexibility to pick strength for 
the various roles.
Thus you pick the ECDSA algorithm that your KSK role needs/demands.

	Olafur