Subject: [dnsext] about draft-hoffman-dnssec-ecdsa-03.txt

From: Francis Dupont <[email-masked]>
Date: Wed, 18 Aug 2010 22:25:26 +0200

I have 3 questions/comments/concerns about this document:

 1- IMHO the SHA-384 DS spec should be moved into a stand-alone
  document. BTW:
   * the relationship between ECDSA and SHA-384 DS is unclear,
    at least it was not written down.
   * there is no equivalent of the RFC 4509 6.1. This is true
    for GOST (RFC 5933) too, i.e., we need a document about
    relative strengths of DS algorithms (a relative ordering)
    and what to do in order to avoid downgrade attacks, even
    I don't believe we already have a real world problem.

 2- some informative details are missing, for instance a private
  key is a (big) number of the same size than the EC group.

 3- the last point can become more important: with previous algorithms
  of the same kind, even for the RSASHA256/RSASHA512 pair, the key
  size offers the freedom to choose the 'strength'. This is no
  longer true for ECDSA so if someone wants to use ECDSAP256SHA256
  for ZSKs and ECDSAP384SHA384 for KSKs (s)he gets some trouble
  with RFC 4035 requirements, for instance:
   There MUST be an RRSIG for each RRset using at least one DNSKEY of
   each algorithm in the zone apex DNSKEY RRset.
  (BTW these requirements are by them-selves the subject of another
   discussion).

Thanks

[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 18 Aug 2010 14:12:41 -0700

At 10:25 PM +0200 8/18/10, Francis Dupont wrote:
>  document.

It doesn't seem useful to create another RFC just so we can have more RFCs. If someone wants to use SHA-384 without ECDSA, they can still point to this eventual RFC.

>BTW:

Section 4 defines two signing algorithms where the key sizes and the hash sizes are matched:
   o  DNSKEY and RRSIG RRs signifying ECDSA with the P-256 curve and
      SHA-256 use the algorithm number {TBA-2}.

   o  DNSKEY and RRSIG RRs signifying ECDSA with the P-384 curve and
      SHA-384 use the algorithm number {TBA-3}.
It would be silly to have a mismatched pair of algorithms because that lets an attacker try to break the weaker of the pair. (And, yes, I know that people are currently doing silly things like RSA2048-with-SHA-1, but I don't think we want to keep promoting things like that...)

>   * there is no equivalent of the RFC 4509 6.1.

Good catch! I'll add a pointer to all of RFC 4509 section 6 to the security considerations.

>  key is a (big) number of the same size than the EC group.

That isn't a "detail", it is an inherent part of the elliptic curves used in the document. I don't think it is appropriate to have an entire treatise on the properties of the elliptic curves here, just as it wasn't required for any of the other RFCs that use P256 and P384.

>  (BTW these requirements are by them-selves the subject of another

That doesn't seem to be a problem, or at least any more problem than if you wanted to use RSA in one place and ECDSA in another. Unless you are saying that we should not allow any signature algorithm other than RSA, the same problem will exist.

--Paul Hoffman, Director
--VPN Consortium

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 19 Aug 2010 10:30:41 +0200

Hi Paul, Francis,

On 08/18/2010 11:12 PM, Paul Hoffman wrote:
> It doesn't seem useful to create another RFC just so we can have more
> RFCs. If someone wants to use SHA-384 without ECDSA, they can still
> point to this eventual RFC.

Agree with Paul.

>> BTW: * the relationship between ECDSA and SHA-384 DS is unclear, at
>> least it was not written down.

I think for hash strengths some future document could be written about
strengths, right now it is pretty clear that 384 has more bits than the
others, and thus would be preferable.  (I understand the math might
break differently as the algorithms are different).

It is possible to avoid 'picking the strongest', by changing the
requirement 'to ignore the weaker algorithm' to 'every DS hash algorithm
must have a match'.  (Similar to 4035sec2.2 text about DNSKEY
algorithms).  This would also protect against downgrades, but by forcing
both hash algorithms to match, so without having to pick favorites.
Given signing requirements this change is backwards compatible.
However, the ecdsa draft is not the place for changes to the handling of
multiple hash algorithms (if this needs to be changed).

>> 3- the last point can become more important: with previous
>> algorithms of the same kind, even for the RSASHA256/RSASHA512 pair,
>> the key size offers the freedom to choose the 'strength'. This is
>> no longer true for ECDSA so if someone wants to use
>> ECDSAP256SHA256 for ZSKs and ECDSAP384SHA384 for KSKs (s)he gets
>> some trouble with RFC 4035 requirements, for instance: There MUST
>> be an RRSIG for each RRset using at least one DNSKEY of each
>> algorithm in the zone apex DNSKEY RRset. (BTW these requirements
>> are by them-selves the subject of another discussion).
> 
> That doesn't seem to be a problem, or at least any more problem than
> if you wanted to use RSA in one place and ECDSA in another. Unless
> you are saying that we should not allow any signature algorithm other
> than RSA, the same problem will exist.

What could be possible is to make one DNSKEY algorithm ID, TBA-2, and
use the length of the DNSKEY key data to signify the ECDSA key size.
P-256 would store 2 256-bit numbers, P-384 stores 2 384 bit numbers and
so on.  Then the zone can be signed with the TBA-2 number, and use a
longer key for the KSK than for ZSK.  It is SHA256 or SHA384 also
depending on the key-size which is 'different'.  There must then be
fixed list of key sizes and the ec groups used.

Best regards,
   Wouter