Subject: [DNSOP] New Version of draft-ietf-dnsop-algorithm-update-00: Algorithm Implementation Requirements and Usage Guidance for DNSSEC

From: Ondřej Surý <[email-masked]>
Date: Thu, 22 Mar 2018 15:08:25 +0000

Hi,

Tim has poked me and Paul W. that WG have actually accepted Algorithm Implementation Requirements and Usage Guidance for DNSSEC as a working group document.

I have updated the draft and submitted is as a WG document and meanwhile it sits there patiently for WG chair approval, you can look at the github version meanwhile:

https://github.com/oerdnj/draft-ietf-dnsop-algorithm-update

Pull/Merge Requests, Issues, etc. are welcome.

The most of the work done between the last version and this is:

* Removal of MUST-, SHOULD+, etc…
* Upgrade the urgency of deploying ECC
* Separate operational recommendations for default algorithm to ECDSAP256SHA256
* Deprecation of ECC-GOST (that actually happened elsewhere, so we reflect it here)

I also squeezed paragraph about DS algorithm upgrade to operational considerations based on Roy Arends’ presentation.

Ondrej
--
Ondřej Surý
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 22 Mar 2018 13:27:38 -0400 (EDT)

> * Deprecation of ECC-GOST (that actually happened elsewhere, so we reflect it here)

As for the DS algorithm 4, SHA-384 does not really add anything over
SHA-256, so it would be good to move that further down from MAY to MUST
NOT on the creation (not validation) part. I'm afraid the current
listing might appear as "it is MAY now but will become MUST in the
future".

Based on Viktor's data, the ratio of SHA256 to SHA384 is 500:1 with
only 8649 DS SHA384 records. Even GOST which is MUST NOT has 4x more
DS records deployed with 36388 records.

I think this text also needs an update:

 	RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although zones
 	deploying it are recommended to switch to ECDSAP256SHA256 as there is
 	an industry-wide trend to move to elliptic curve cryptography.

They should switch away from SHA1 as SHA1 is being deprecated industry
wide. Even if we recommend to move away from RSA (which I'm not sure if there
is consensus on) to ECC, I would like to move them to ED25519/ED448 over
the ECDSA* variants. If it is too soon for that now, I would simply not
recommend moving away from RSA. And maybe make ECDSAP256SHA256 a MAY
instead of a MUST.

Paul

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 22 Mar 2018 17:47:58 +0000

--
Ondřej Surý
[email-masked]

> On 22 Mar 2018, at 17:27, Paul Wouters <[email-masked]> wrote:
> 

Sounds good to me, you already have access to the repo :).

> the ECDSA* variants.

I don’t think this is currently feasible to do so, so we need to have a feedback from WG.

> If it is too soon for that now, I would simply not

What would be the technical/security reason for skipping ECDSA?

Ondrej

---

From: Frederico A C Neves <[email-masked]>
Date: Thu, 22 Mar 2018 14:56:06 -0300

On Thu, Mar 22, 2018 at 05:47:58PM +0000, Ondřej Surý wrote:
... 
> What would be the technical/security reason for skipping ECDSA?

Besides of this question this is a recommendation to be change in the
future. Current ED25519/ED448 deployment is negligible if any. It will
take at least 5 year for the situation to improve.

Fred

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 23 Mar 2018 15:58:02 +0000

> is consensus on) to ECC, I would like to move them to ED25519/ED448 over

I think it is, unfortunately, much too early for such a move.  For
example, on Unix systems the requisite OpenSSL 1.1.x libraries that
provide the Edwards EC algorithms, are not yet out of beta!  It
will be some years before Ed25519 and Ed448 can be expected to be
widely supported by resolvers.  Therefore, I would still strongly
recommend ECDSA, which is widely supported.

We should certainly encourage the implementation of Ed25519/Ed448
in resolver and nameserver implementations, but it is much too
early for adoption, beyond dual DS/KSKs one ECDSA and another
Ed25519, with the client choosing whichever it prefers.  ZSKs should
IMHO migrate to ECDSA for now to alleviate packet size issues.

> If it is too soon for that now, I would simply not recommend moving away
> from RSA. And maybe make ECDSAP256SHA256 a MAY instead of a MUST.

I disagree.  ECDSA is widely adopted, and more adoption will help
to reduce packet sizes and improved performance of online signing
where desired (load-balaced responses with DNSSEC, ...).

-- 
	Viktor.

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 23 Mar 2018 16:14:20 +0000

I agree with Victor and I believe this is what the draft currently says and recommends.

Ondřej 
--
Ondřej Surý — ISC

> On 23 Mar 2018, at 15:58, Viktor Dukhovni <[email-masked]> wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Frederico A C Neves <[email-masked]>
Date: Fri, 23 Mar 2018 14:48:12 -0300

> IMHO migrate to ECDSA for now to alleviate packet size issues.

This is exactly one of our, .br. reasonings for moving forward to EC
now.

Talking this conversation to the root, all this rollover hurdles would
be much smaller, if any. We could leave with a Double signing for a
long time. With ECDSAP256/Ed25519 the keyset would be much smaller
than the current one, aparently we're about to roll the zsk, ~ 1/4 of
the size. And the signature would be ~ 1/2 of the current single
RSA2048 size.

Fred

---

From: Paul Wouters <[email-masked]>
Date: Fri, 23 Mar 2018 19:41:30 +0000

> On Mar 23, 2018, at 15:58, Viktor Dukhovni <[email-masked]> wrote:
> 
> 

That’s fair. I take back my suggestion.

Paul

---

From: Michael Sinatra <[email-masked]>
Date: Mon, 26 Mar 2018 17:30:20 -0700

> I also squeezed paragraph about DS algorithm upgrade to operational considerations based on Roy Arends’ presentation.

Regarding the comments (and general tone of the document) regarding
SHA384 and ECDSAP384SHA384:

I am a bit uncomfortable with the document's disrecommendation of SHA384
and ECDSAP384SHA384.  The main reason for this is that for crypto
recommendations here in the USG, I often point people to the successor
of the NSA Suite B recommendations, now called the "Commercial National
Security Algorithm Suite" or CNSA.  The recommendations here call for
SHA384 and P-384:

https://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.cfm

This document made a bit of a splash by pointing out that ECC is not
really quantum-resistant, which led to lots of "theories" as to why
NSA-IAD was making that claim.  But the main utility of the document is
the crypto strength recommendations in the document.

I am *very* sympathetic to the argument that P-256 and SHA-256 are "good
enough" for DNSSEC, especially since we can expect any such signatures
to have expired by the time 112-bit security is completely obsolete.  My
motivation is around encouraging people to use the strongest security
available to them without having to worry about whether some
applications could get away with weaker security or not.

Given that ECDSAP384SHA384 signatures and key lengths are still
significantly smaller than RSASHA256, the adage of "use the strongest
*practical* security algorithm that's available" would still seem to
point to ECDSAP384SHA384.  For this reason, I am not comfortable with
the statement:

"ECDSAP384SHA384 share the same properties as ECDSAP256SHA256, but
offers only a little advantage over ECDSAP256SHA256 and has not seen
wide deployment, so the usage of this algorithm is discouraged,
especially for signing."  I would also advocate changing the Signing
Recommendation to "MAY."

michael

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 27 Mar 2018 10:04:03 +0200

Hi Michael,

> On 27 Mar 2018, at 02:30, Michael Sinatra <[email-masked]> wrote:
> 
> 
> 

Perhaps, we could say: “offers only a little advantage for DNSSEC over …” as that would be more accurate.

We are (should be) aiming for most practical secure algorithm and that’s ECDSAP256SHA256 at the moment, and ED25519 in a foreseeable future (when there’s enough deployed base). It’s always search for a balance, and given there’s already huge deployed base for ECDSAP256SHA256, I think that discouraging users to use P384 is a reasonable thing to do.

> especially for signing.”

…but the document authors are open to other suggestions, it’s a WG document, so we will follow WG advice.

> I would also advocate changing the Signing
> Recommendation to "MAY.”

That would be fine with me (also to align with ED448 that share many of the properties of P384). I also expect that no implementation would actually rip-out P384 implementation they already have, and for new implementations the recommendation of SHOULD NOT and MAY is of similar value.

Cheers,
Ondrej
--
Ondřej Surý
[email-masked]

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 27 Mar 2018 05:43:46 -0700

On 26 Mar 2018, at 17:30, Michael Sinatra wrote:

> recommendations here in the USG,

Note that those are for encryption, where they want to keep some things 
secret for 40 or more years. DNSSEC is an authentication mechanism. If 
it takes two decades to break an P256 key that is used for encryption, 
the attacker gets much (much!) more value than breaking one that is used 
for authentication.

The fact that the NSA document is unclear on this point has been causing 
problems for many people, including for people inside the NSA.

--Paul Hoffman

---

From: Michael Sinatra <[email-masked]>
Date: Tue, 27 Mar 2018 10:21:59 -0700

> the attacker gets much (much!) more value than breaking one that is used

Agree, and I would even add that the limited signature validity interval
of DNSSEC makes ECDSAP256SHA256 more than "good enough" for DNSSEC.
However, my motivation is based on your next point...

> problems for many people, including for people inside the NSA.

My goal is to basically avoid confusion and just tell people to use the
strongest algorithm they can reasonably use.  I.e. follow the CNSA
recommendations and don't spend a lot of time thinking about the
application.

I'll try to come up with some wording for the draft (i.e. the sentence
that I was uncomfortable with) that captures the notion that
P-384/SHA384 doesn't add much in the way of security, but that there's
nothing wrong with "crypto maximalism" in this case, and see what the WG
thinks.

michael

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 27 Mar 2018 10:22:23 -0700

> recommendations and don't spend a lot of time thinking about the

The CNSA will likely be updated in the future to actually deal with the 
issues, or be supplanted altogether with something from a different 
agency that is better written. Telling people "just follow this 
poorly-worded doc" is not what this WG should be doing.

--Paul Hoffman

---

From: Michael Sinatra <[email-masked]>
Date: Tue, 27 Mar 2018 11:39:51 -0700

> poorly-worded doc" is not what this WG should be doing.

Hi Paul:

To be clear, I am not asking the WG to refer to the CNSA.  I am merely
asking the WG not to create something that can be construed as
fundamentally inconsistent with it.

I propose replacing:

especially for signing."

WITH:

"ECDSAP384SHA384 share the same properties as ECDSAP256SHA256, but
offers a modest security advantage over ECDSAP256SHA256 (192-bits of
strength versus 128-bits).  For most applications of DNSSEC,
ECDSAP256SHA256 should be satisfactory and robust for the foreseeable
future, and is therefore recommended for signing.  While it is unlikely
for a DNSSEC use case which requires 192-bit security strength to arise,
ECDSA384SHA384 is provided for such applications and it MAY be used for
signing in these cases."

This also makes the discussion in this draft more consistent with RFC
6605's discussion of ECDSAP384SHA384 and RFC 8080's discussion of Ed448.

michael