Subject: [DNSOP] Fwd: New Version Notification for draft-sury-dnskey-ed25519-03.txt

From: Ondřej Surý <[email-masked]>
Date: Tue, 8 Sep 2015 11:19:13 +0200 (CEST)

Dear DNS colleagues,

this might be of some interest to you.

Cheers,
--
 Ondřej Surý -- Technical Fellow
 --------------------------------------------
 CZ.NIC, z.s.p.o.    --     Laboratoře CZ.NIC
 Milesovska 5, 130 00 Praha 3, Czech Republic
 mailto:[email-masked]    https://nic.cz/
 --------------------------------------------

----- Forwarded Message -----
From: [email-masked]
To: "Ondřej Surý" <[email-masked]>, "Robert Edmonds" <[email-masked]>, "Ondřej Surý" <[email-masked]>, "Robert Edmonds" <[email-masked]>
Sent: Tuesday, September 8, 2015 11:17:58 AM
Subject: New Version Notification for draft-sury-dnskey-ed25519-03.txt

A new version of I-D, draft-sury-dnskey-ed25519-03.txt
has been successfully submitted by Ondrej Sury and posted to the
IETF repository.

Name:		draft-sury-dnskey-ed25519
Revision:	03
Title:		Ed25519 for DNSSEC
Document date:	2015-09-08
Group:		Individual Submission
Pages:		7
URL:            https://www.ietf.org/internet-drafts/draft-sury-dnskey-ed25519-03.txt
Status:         https://datatracker.ietf.org/doc/draft-sury-dnskey-ed25519/
Htmlized:       https://tools.ietf.org/html/draft-sury-dnskey-ed25519-03
Diff:           https://www.ietf.org/rfcdiff?url2=draft-sury-dnskey-ed25519-03

Abstract:
   This document describes how to specify Ed25519 keys and signatures in
   DNS Security (DNSSEC).  It uses the Ed25519 instance of the Edwards-
   curve Digital Signature Algorithm (EdDSA) with the SHA-512 hash
   algorithm.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 9 Sep 2015 16:55:15 +0000

> this might be of some interest to you.

Thanks.  Shouldn't this wait for the CFRG to finalize the new EC
signature schemes?  We already have too many DNSSEC algorithm ids,
and are likely to add very similar code points once CFRG is done
RSN.

So I'd prefer to see this delayed until the signature schemes for
the new CFRG curves are done.

--
	Viktor.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 9 Sep 2015 20:12:41 +0200 (CEST)

Hi Viktor,

yes, we are waiting exactly for the cfrg to finish the signature schemas.  But the rest can get a review early.

f.e. it's evident now, we have to add more material about motivation to add new curves into the draft(s).

Cheers,
Ondrej

----- Original Message -----
> From: "Viktor Dukhovni" <[email-masked]>
> To: [email-masked]
> Sent: Wednesday, September 9, 2015 6:55:15 PM
> Subject: Re: [DNSOP] Fwd: New Version Notification for draft-sury-dnskey-ed25519-03.txt

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 9 Sep 2015 19:29:46 +0000

On Wed, Sep 09, 2015 at 08:12:41PM +0200, Ondřej Surý wrote:

> Yes, we are waiting exactly for the cfrg to finish the signature schemas.
> But the rest can get a review early.  f.e. it's evident now, we have to
> add more material about motivation to add new curves into the draft(s).

Great.  My other concern is that at this point, perhaps every time
we consider adding more algorithm ids to DNSSEC we should consider
retiring some old ones, we are starting to have too many:

   Id    Description           Mnemonic        ZSIG TSIG   Reference
   -------------------------------------------------------------------------
    1    RSA/MD5 (deprecated)  RSAMD5             N    Y   [RFC3110][RFC4034]
    2    Diffie-Hellman        DH                 N    Y   [RFC2539]
    4    Reserved                                          [RFC6725]
    9    Reserved                                          [RFC6725]
    11   Reserved                                          [RFC6725]
    --
    3    DSA/SHA1              DSA                Y    Y   [RFC3755]
    5    RSA/SHA-1             RSASHA1            Y    Y   [RFC3110][RFC4034]
    6    DSA-NSEC3-SHA1        DSA-NSEC3-SHA1     Y    Y   [RFC5155]
    7    RSASHA1-NSEC3-SHA1    RSASHA1-NSEC3-SHA1 Y    Y   [RFC5155]
    8    RSA/SHA-256           RSASHA256          Y    *   [RFC5702]
    10   RSA/SHA-512           RSASHA512          Y    *   [RFC5702]
    12   GOST R 34.10-2001     ECC-GOST           Y    *   [RFC5933]
    13   P-256 with SHA-256    ECDSAP256SHA256    Y    *   [RFC6605]
    14   P-384 with SHA-384    ECDSAP384SHA384    Y    *   [RFC6605]

I'd like to propose that with the introduction of the CFRG algorithms,
we should deprecate:

    3    DSA/SHA1              DSA                Y    Y   [RFC3755]
    6    DSA-NSEC3-SHA1        DSA-NSEC3-SHA1     Y    Y   [RFC5155]
    12   GOST R 34.10-2001     ECC-GOST           Y    *   [RFC5933]

and as ideally also announce a sunset date for:

    5    RSA/SHA-1             RSASHA1            Y    Y   [RFC3110][RFC4034]
    7    RSASHA1-NSEC3-SHA1    RSASHA1-NSEC3-SHA1 Y    Y   [RFC5155]

though of course these are rather widely used at present, it is
time to start encouraging folks to move on.

Once the CFRG algorithms are done, I would also publish an updated
list of MTI algorithms for DNSSEC that would consist of:

    8, 12 and both of the CFRG algorithms.

The more secure of the two CFRG algorithms should be supported by
clients, but should not yet be used by servers, concerns about
post-QC crypto don't really apply to short-term signatures, we can
switch to the Goldilocks curve if/when necessary, provided the
client support is there all along.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 10 Sep 2015 11:10:51 +1000

It isn't the count of algorithms, it's the size of the algorithm
field that is the issue (8 bits) though we could hack in a extension.
We can invent lots of algorithms but we really need to have a good
justifation to add it to the table.  Why is this algorithm
*significantly* better than all of the existing algorithms.

Mark

In message <[email-masked]>, Viktor Dukhovni writ
es:
> On Wed, Sep 09, 2015 at 08:12:41PM +0200, Ondej Sur wrote:
>
>     1    RSA/MD5 (deprecated)  RSAMD5             N    Y   RFC3110RFC4034
>     2    Diffie-Hellman        DH                 N    Y   RFC2539
>     4    Reserved                                          RFC6725
>     9    Reserved                                          RFC6725
>     11   Reserved                                          RFC6725
>     --
>     3    DSA/SHA1              DSA                Y    Y   RFC3755
>     5    RSA/SHA-1             RSASHA1            Y    Y   RFC3110RFC4034
>     6    DSA-NSEC3-SHA1        DSA-NSEC3-SHA1     Y    Y   RFC5155
>     7    RSASHA1-NSEC3-SHA1    RSASHA1-NSEC3-SHA1 Y    Y   RFC5155
>     8    RSA/SHA-256           RSASHA256          Y    *   RFC5702
>     10   RSA/SHA-512           RSASHA512          Y    *   RFC5702
>     12   GOST R 34.10-2001     ECC-GOST           Y    *   RFC5933
>     13   P-256 with SHA-256    ECDSAP256SHA256    Y    *   RFC6605
>     14   P-384 with SHA-384    ECDSAP384SHA384    Y    *   RFC6605
>
>     3    DSA/SHA1              DSA                Y    Y   RFC3755
>     6    DSA-NSEC3-SHA1        DSA-NSEC3-SHA1     Y    Y   RFC5155
>     12   GOST R 34.10-2001     ECC-GOST           Y    *   RFC5933
>
>     5    RSA/SHA-1             RSASHA1            Y    Y   RFC3110RFC4034
>     7    RSASHA1-NSEC3-SHA1    RSASHA1-NSEC3-SHA1 Y    Y   RFC5155
>

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Wed, 9 Sep 2015 21:44:23 -0400 (EDT)

>> time to start encouraging folks to move on.

Most people on 5 or 7 are only on it because their software does not
support an algorithm roll (like current opendnssec). I'm not sure if
declaring sunset will help them get un-stuck.

>>     8, 12 and both of the CFRG algorithms.

You listed 12 as both deprecate and MTI ?

>> post-QC crypto don't really apply to short-term signatures

I thought the whole point of QC was that it makes key discovery
a trivial short brute force. It would be especially useful for
short term signatures that otherwise couldn't have been broken in
time (although I guess if you have QC, you do the root key first.

Paul

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 10 Sep 2015 16:02:37 +0200 (CEST)

Viktor,

while I wholeheartedly agree that we might deprecate DSA, and perhaps issue a recommendation on what is the minimum recommended algorithm, this is really out-of-the-scope for the cfrg curves draft.  I would be happy to help (co-author, review, etc..) the deprecation I-D/RFC, I think we should not mix these together, since it will be much harder to agree upon the deprecated algorithm list.

Cheers,
Ondrej

----- Original Message -----
> Sent: Wednesday, September 9, 2015 9:29:46 PM

---

From: "Rose, Scott" <[email-masked]>
Date: Thu, 10 Sep 2015 10:26:14 -0400

There is a current document that would need to be updated: RFC 6944:
http://tools.ietf.org/html/rfc6944

The RFC needs to be updated to include the new elliptic curve 
algorithms.  It would also be a good place to move other algorithms to 
other categories.

Scott

On 10 Sep 2015, at 10:02, Ondřej Surý wrote:

> Viktor,
>
> while I wholeheartedly agree that we might deprecate DSA, and perhaps 
> issue a recommendation on what is the minimum recommended algorithm, 
> this is really out-of-the-scope for the cfrg curves draft.  I would be 
> happy to help (co-author, review, etc..) the deprecation I-D/RFC, I 
> think we should not mix these together, since it will be much harder 
> to agree upon the deprecated algorithm list.
>
> Cheers,
> Ondrej
> --

==================================
Scott Rose, NIST
[email-masked]
ph: +1-301-975-8439
Google Voice: +1-571-249-3671

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 Sep 2015 15:59:09 +0000

> You listed 12 as both deprecate and MTI ?

Sorry, typo, I meant 13 as MTI not 12.

> time (although I guess if you have QC, you do the root key first.

My point is that once a DNSSEC KSK or ZSK is changed, there is no
issue with disclosure.  The keys are used for signing only.  So we
don't need to worry about QC now.  We can replace any weak keys
once quantum computers are reasonably expected to be available to
adversaries.

-- 
	Viktor.