Subject: [DNSOP] Introducing draft-wouters-sury-dnsop-algorithm-update

From: Paul Wouters <[email-masked]>
Date: Sat, 19 Mar 2016 15:43:58 -0400 (EDT)

Hi,

there was an interest in deprecating some DNSSEC related algorithms.
Ondrey and I wrote a draft that tries to introduce and depricate
DNSSEC algorithms similar to how it has been done for IKE in RFC4307
and 4307bis:

Comments, feedback would be great :)

https://tools.ietf.org/html/draft-wouters-sury-dnsop-algorithm-update

Paul

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 19 Mar 2016 16:04:06 -0400

[[ Dropping CURDLE because these discussions should only be in one WG ]]

> https://tools.ietf.org/html/draft-wouters-sury-dnsop-algorithm-update

This draft is mostly good, and would be a good addition to DNSOP.

I have two technical issues with the -00 that can easily be resolved.

    ECC-GOST is at the SHOULD level because it has not seen wide
    deployment.

GOST is a "national algorithm", meaning that it is used almost 
exclusively in only one country (in this case Russia). National 
algorithms should not be promoted in the IETF unless they are used more 
widely *and* there is a good body of cryptographic research showing that 
they are as good as similar algorithms. GOST has neither. Proposal: drop 
it from this document. It will remain in the IANA registry, of course.

    ECDSAP256SHA256 and ECDSAP384SHA384 provide more strength for
    signature size than RSASHA256 and RSASHA512 variants.  It is 
expected
    to be raised to MUST once they have been deployed more widely for
    DNSSEC Signing.  ECDSAP256SHA256 has seen raise in the deployment, 
so
    it's set to MUST level for DNSSEC Validation.

Even though I was a strong proponent of ECDSA, I think this is the wrong 
move. ECDSA has had many years to garner interest, and it hasn't. Within 
a year, we will have EDDSA in DNSSEC, and the operational crypto 
properties of EDDSA are noticeably better than those of ECDSA. It would 
be much better if the community just standardized on EDDSA instead of a 
mixture of the two algorithms. Proposal: drop them from this document. 
They will remain in the IANA registry, of course.

--Paul Hoffman

---

From: Suzanne Woolf <[email-masked]>
Date: Sun, 20 Mar 2016 09:53:39 -0400

> [[ Dropping CURDLE because these discussions should only be in one WG ]]

As a side note: the authors asked the chairs of both DNSOP and CURDLE where they should bring the draft; it seemed to at least the chairs that DNSOP should probably take the lead because what the draft is trying to accomplish is largely DNS-specific, but that review in both WGs would be beneficial.

It's probably a good idea to have separate threads for different lists as discussion proceeds.

Suzanne

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Sun, 20 Mar 2016 13:55:38 -0400

On Sat, Mar 19, 2016 at 4:04 PM, Paul Hoffman <[email-masked]> wrote:

>    signature size than RSASHA256 and RSASHA512 variants.  It is expected
>    DNSSEC Signing.  ECDSAP256SHA256 has seen raise in the deployment, so
> move. ECDSA has had many years to garner interest, and it hasn't. Within a
> year, we will have EDDSA in DNSSEC, and the operational crypto properties
> of EDDSA are noticeably better than those of ECDSA. It would be much better
> if the community just standardized on EDDSA instead of a mixture of the two
> algorithms. Proposal: drop them from this document. They will remain in the
> IANA registry, of course.
>
> --Paul Hoffman
>
> Paul for the record
There are tens of thousands of domains signed with ECDSAP256SHA256 world
wide.
ECDSA is currently the only viable algorithm for anyone that wants to do
OnLine signing in low latency environments.

There are significant issues related to deploying a new DNSSEC algorithm
world wide, most related to stuff actual operating environments. My current
best guess is that it takes about 5-10years after IETF standardizes new
algorithm, before the algorithm is globally "useful". We are still inside
the 5 year window, working out the issues in deploying new algorithms with
ECDSA can only help the algorithms that will follow.
I see no evidence of use of ECDSAP384SHA384 except in test setups, so I
have no problem not mentioning that  algorithm in the document.

Olafur

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 20 Mar 2016 11:55:34 -0700

> OnLine signing in low latency environments.

Yes, but that doesn't change what I said. Most of those domains are 
signed by one entity who can change easily if the operational market 
thinks that is a good idea.

> world wide, most related to stuff actual operating environments.

Sure.

> My current
> algorithm, before the algorithm is globally "useful".

And yet you chose to deploy sooner:

> We are still inside

Right, particularly because EDDSA has notable *operational* advantages 
over ECDSA.

> have no problem not mentioning that  algorithm in the document.

The 256/384 issue is a separate one, but one worth discussing. FWIW, I 
agree that mentioning it, maybe even suggesting against its use, would 
be good.

--Paul Hoffman

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Sun, 20 Mar 2016 15:34:29 -0400

On Sun, Mar 20, 2016 at 2:55 PM, Paul Hoffman <[email-masked]> wrote:

>>> a
> Yes, but that doesn't change what I said. Most of those domains are signed
> by one entity who can change easily if the operational market thinks that
> is a good idea.

Right now there are two options for on-line signers GOST-ECC and
ECDSAP256SHA256
no other alternative will be useful for many years, so our choice was
signing pain or deployment pain.
We picked the deployment pain due to size and signature strength factors.

Your statement can be read to mean that ECC should not be used because
ECDSA has no advantages over
RSA with 1024 bit keys, I know that was not what you wanted to say.

There are at least 2 other parties that I'm aware that are working on their
own online signing systems using the same
algorithm as we are.

> And yet you chose to deploy sooner:

See above, and I did not know at the beginning how hard it is to move the
ecosystem,
so consider this a service to future vanity algorithms.

> Right, particularly because EDDSA has notable *operational* advantages

define operational!!!
>From my point operational is all about the running systems, and how data
gets into those systems.
I fail to see how crypto advantages help that. If it is faster that might
be an advantage.

> agree that mentioning it, maybe even suggesting against its use, would be
> good.

For the record I never wanted ECDSAP384SHA384 defined, will support having
it obsoleted.
Fewer algorithms are better for DNSSEC.

Olafur

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 20 Mar 2016 13:15:26 -0700

> Right now there are two options for on-line signers GOST-ECC and

Correct. Later this year there will be a third. Nothing in this thread 
suggests otherwise.

> signing pain or deployment pain.

Can you say how you predict "many years"? The rollout of ECDSA in code 
was pretty fast. If EDDSA is rolled into the same resolver software, and 
if those resolvers do an update (as it appears many do), then it will be 
as useful as ECDSA.

> We picked the deployment pain due to size and signature strength 

Correct. You will get exactly the same for EDDSA, and have better 
operational security properties.

> RSA with 1024 bit keys,

I can't see how, but you seem to see things differently.

> I know that was not what you wanted to say.

Then why did you bring it up? It goes against everything that I have 
said in standards-track documents for over a decade, particularly in RFC 
3766.

> own online signing systems using the same

This is good to hear. Do you believe that they (or you) would not be 
able to change algorithms if you use software that includes it?

> I fail to see how crypto advantages help that.

Quoting from the document that we are discussing in this thread:
    It does not require the use of a unique random number for each
    signature, there are no padding or truncation issues as with ECDSA,
    and it is more resilient to side-channel attacks.
Both of those advantages help operators keep their private keys secret. 
Most operators would find that useful.

> If it is faster that might
> be an advantage.

EDDSA might be a bit faster, but that is not nearly as significant as 
the other features.

> Fewer algorithms are better for DNSSEC.

Fully agree here.

Again, what I proposed would not prevent or discourage anyone from 
signing with ECDSA if they wanted to: it would simply not encourage it.

--Paul Hoffman

---

From: "Rose, Scott" <[email-masked]>
Date: Mon, 21 Mar 2016 09:53:55 -0400

This draft should also serve to obsolete RFC 6944.

Scott

On 19 Mar 2016, at 15:43, Paul Wouters wrote:

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

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

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Mar 2016 11:13:11 -0400 (EDT)

> This draft should also serve to obsolete RFC 6944.

Just submitted -01 which does that, and also adjusts the levels for GOST
and ECDSAP384SHA384.

https://tools.ietf.org/rfcdiff?url2=draft-wouters-sury-dnsop-algorithm-update-01.txt

https://tools.ietf.org/html/draft-wouters-sury-dnsop-algorithm-update-01

Paul

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 22 Mar 2016 09:03:51 +0100

On Sat, Mar 19, 2016 at 04:04:06PM -0400,
 Paul Hoffman <[email-masked]> wrote 
 a message of 51 lines which said:

> exclusively in only one country (in this case Russia).

Five (5) domains in .fr are signed with GOST :-)