Subject: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-algorithm-update

From: Tim Wicinski <[email-masked]>
Date: Tue, 2 Oct 2018 08:51:21 -0400

The chairs and the authors of this document feel that the
document is in solid shape to proceed to WGLC.

This starts a Working Group Last Call for draft-ietf-dnsop-algorithm-update

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/

The Current Intended Status of this document is: Proposed Standard

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please speak
out with your reasons.

This starts a two week Working Group Last Call process, and ends on:  16
October 2018

thanks
tim

---

From: Loganaden Velvindron <[email-masked]>
Date: Tue, 2 Oct 2018 17:40:56 +0400

> https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/

Section 3.1.

"
 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.
"

And also this paragraph:
"

RSASHA256 is in wide use and considered strong.

"

My suggestion would be to include figures or at minimum a reference.
There is a document from ISOC with 3 tables where there is an analysis
of deployment DNSSEC worldwide.

https://www.internetsociety.org/wp-content/uploads/2017/08/ISOC-State-of-DNSSEC-Deployment-2016-v1.pdf,
Page 23 & Page 24.

> If someone feels the document is *not* ready for publication, please speak out with your reasons.
>
> This starts a two week Working Group Last Call process, and ends on:  16 October 2018
>
> thanks
> tim
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 14 Oct 2018 05:55:22 -0400

Follow up on WGLC for draft-ietf-dnsop-algorithm-update:

We're still looking for comments from the WG on advancing or not advancing
this document through the standards process.
While a percentage of the WG is at OARC (and maybe even RIPE), why not take
a few moments and elicit some comments
on this.

thanks
Tim

---

From: Ondřej Surý <[email-masked]>
Date: Sun, 14 Oct 2018 14:15:56 +0200

Hi Loganaden,

while I understand what you are asking for, I don’t understand how it would improve the document.

IETF RFCs are static and if we include any current “numbers” they quickly become invalid.  Adding figures to the document doesn’t improve readability or the content.  While it would support the claims we make in the document I feel that the consensus process IETF have is just fine for giving the content enough validity, and we don’t have to support every claim we make in the document with figures.

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

> On 2 Oct 2018, at 15:40, Loganaden Velvindron <[email-masked]> wrote:
>

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Sun, 14 Oct 2018 14:57:33 +0200

Tim,
I have reviewed the document and it is ready for publication

Olafur

-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com

---

From: Ted Lemon <[email-masked]>
Date: Sun, 14 Oct 2018 09:05:20 -0400

I've been using the document for the DNSSD Service Registration Protocol
work; it's useful, and should be published.

On Sun, Oct 14, 2018 at 5:55 AM Tim Wicinski <[email-masked]> wrote:

> While a percentage of the WG is at OARC (and maybe even RIPE), why not
> take a few moments and elicit some comments
> on this.
>
> thanks
> Tim
>
>

---

From: [email-masked]
Date: Tue, 16 Oct 2018 00:04:57 +0900 (JST)

WGLC comment to draft-ietf-dnsop-algorithm-update-02

Section 3.2 is "recommendations for operators".

There is texts that discuss ECDSAP256SHA256 only in section 3.2.
However, RSASHA256 is still usable.
Please add text about other algorithms.
if there is a table similar to section 3.1, it will help operators.

For example,
                 choice of                | choice of
                 sigining algorithm (now) | sigining algorithm (2 years Later)
  ----------------------------------------------------------------------------
  RSASHA1*        MUST NOT                | MUST NOT
  RSASHA256       usable                  | usable/consider change to EC*/Ed*
  ECDSAP256*      usable                  | usable
  Ed25519         MAY                     | usable

Regards,

--
Kazunori Fujiwara, JPRS <[email-masked]>

---

From: "Rose, Scott" <[email-masked]>
Date: Mon, 15 Oct 2018 11:13:10 -0400

I have read the draft and support it advancing.  It is a good 
replacement for RFC 6944.

Scott

On 2 Oct 2018, at 8:51, Tim Wicinski wrote:

> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-algorithm-update%2F&amp;data=02%7C01%7Cscott.rose%40nist.gov%7C308a6e44bb084b0837eb08d62865e3a1%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636740815406311914&amp;sdata=xG%2FSR4lPdeTEZ%2FgxzFGri6a56%2FetNUf6NMjXyJs4%2FJk%3D&amp;reserved=0
>

> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop&amp;data=02%7C01%7Cscott.rose%40nist.gov%7C308a6e44bb084b0837eb08d62865e3a1%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636740815406311914&amp;sdata=9%2BS2iuYcizAHSrx7dZMmYe%2FpNhq5igc%2BewOKyoRQPys%3D&amp;reserved=0

===================================
Scott Rose
NIST ITL
[email-masked]
+1-301-975-8439
GV: +1-571-249-3671
===================================

---

From: [email-masked]
Date: Thu, 18 Oct 2018 06:18:02 +0900 (JST)

What I want to say about draft-ietf-dnsop-algorithm-update-02 are below:

1. About chapter composition

   If section 3.2 is "recommendations for operators",
   Section 3.1 and Section 3.3 are recommendations for software developpers
   and TLD/Root operators.

   # Sometimes TLD/Root do not accept newer algorithms and digests.

2. "recommendations for operators" section

   Section 3.2 lacks texts about RSASHA256 and other algorithms.
   Currently, both RSASHA256 and ECDSAP256SHA256 are first choices
   for operators.

3. texts about DS (and CDS) algorithms recommendation for operators needed

   In section 3.2 or 3.3, please add SHA-256 is necessary and enough
   DS algorithm for operators now.

4. In my opinion, Ed25519 is best algorithm some yars later.
   If the document describes both current RECOMMENDATIONS and
   RECOMMENDATIONS some years later, we can plan.

Regards,

> From: [email-masked]

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 18 Oct 2018 14:11:59 +0200

I agree, but the last paragraph of 3.1 seems to express that already:

> It is expected that ED25519 will become the future RECOMMENDED default
> algorithm once there's enough support for this algorithm in the
> deployed DNSSEC validators.
Do you mean that "expected future recommendations" should be made more
visible in a separate section or something?

--Vladimir

---

From: [email-masked]
Date: Mon, 22 Oct 2018 00:40:19 +0900 (JST)

> From: Vladimír Čunát <[email-masked]>

Yes.

# I'm afraid that some TLD/Root operators may not support ED25519
# because it is RECOMMENDED (not MUST).

> visible in a separate section or something?

Yes. (something)

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 23 Oct 2018 19:39:21 +0200

Fujiwara-san,

I don’t exactly understand why such table would be better than existing text that say:

> 3.2.  DNSKEY Algorithm Recommendation
> 
>    Operation recommendation for new and existing deployments.
> 
>    Due to industry-wide trend to move to elliptic curve cryptography,
>    the ECDSAP256SHA256 is RECOMMENDED for use by new DNSSEC deployments,
>    and users of RSA based algorithms SHOULD upgrade to ECDSAP256SHA256.

I believe this is clear enough.

As for the second column, I am strongly opposed to saying what would the recommendation
be in ‘2 years’.  We have no idea about the deployment of Ed25519 resolvers[*], neither about
RSA.

But this is a type of document that needs to be regularly refreshed when needed, so we can
issue another update in 2-5 years...

Ondrej

* - I also suspect that saying “usable” is too optimistic given that support for Ed25519 requires
new OpenSSL 1.1.0 and the general glacier-speed deployments of new software.
--
Ondřej Surý
[email-masked]

> On 15 Oct 2018, at 17:04, [email-masked] wrote:
>

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 23 Oct 2018 19:51:05 +0200

> On 21 Oct 2018, at 17:40, [email-masked] wrote:
> 

The I-D already says:

>    It is expected that deprecation of an algorithm will be performed
>    gradually.  This provides time for various implementations to update
>    their implemented algorithms while remaining interoperable.  Unless
>    there are strong security reasons, an algorithm is expected to be
>    downgraded from MUST to NOT RECOMMENDED or MAY, instead of to MUST
>    NOT.  Similarly, an algorithm that has not been mentioned as
>    mandatory-to-implement is expected to be introduced with a
>    RECOMMENDED instead of a MUST.

and the last paragraph of 3.1 explicitly says:

>           It is
>           expected that ED25519 will become the future RECOMMENDED
>           default algorithm once there's enough support for this
>           algorithm in the deployed DNSSEC validators.

I don’t think more handholding would be appropriate of IETF RFC.

Thanks for all the comments,
--
Ondřej Surý
[email-masked]