Subject: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-algorithm-update-01.txt

From: Ondřej Surý <[email-masked]>
Date: Tue, 5 Jun 2018 21:02:07 +0200

Dear colleagues,

I incorporated text from Michael Sinatra (thanks for that!) and I think the document
is ready to go.

Could I ask for more reviews, so we can progress this document forward?

The sources are also stored at Microsoft^HGithub:

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

So, if you haven’t deleted your account :), you can also send pull requests.

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

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-ietf-dnsop-algorithm-update-01.txt
> Date: 5 June 2018 at 20:52:20 CEST
> To: "Paul Wouters" <[email-masked]>, "Ondrej Sury" <[email-masked]>
> 
> 
> A new version of I-D, draft-ietf-dnsop-algorithm-update-01.txt
> has been successfully submitted by Ondrej Sury and posted to the
> IETF repository.
> 
> Name:		draft-ietf-dnsop-algorithm-update
> Revision:	01
> Title:		Algorithm Implementation Requirements and Usage Guidance for DNSSEC
> Document date:	2018-06-05
> Group:		dnsop
> Pages:		10
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-dnsop-algorithm-update-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-dnsop-algorithm-update-01
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-algorithm-update
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-algorithm-update-01
> 
> Abstract:
>   The DNSSEC protocol makes use of various cryptographic algorithms in
>   order to provide authentication of DNS data and proof of non-
>   existence.  To ensure interoperability between DNS resolvers and DNS
>   authoritative servers, it is necessary to specify a set of algorithm
>   implementation requirements and usage guidance to ensure that there
>   is at least one algorithm that all implementations support.  This
>   document defines the current algorithm implementation requirements
>   and usage guidance for DNSSEC.  This document obsoletes [RFC6944].
> 
> 
> 
> 
> 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: Thu, 7 Jun 2018 06:39:33 +0000

> Could I ask for more reviews, so we can progress this document forward?

A couple of quick comments:

1.  Perhaps it might not be clear to all readers whether the
    table in Section 3.1 is *software* implementation advice or
    operational deployment advice?

    Seeing that Ed25519 is RECOMMENDED for signing makes me think that
    this software implementation advice, since signing zones with
    Ed25519 seems presently premature.

2.  I see that RSA-SHA512 (algorithm 10) is not recommended for
    signing, and indeed it is not very widely deployed.  Out of
    ~7.6 million signed domains I see ~72k with algorithm 10 ZSKs
    and KSKs, while algorithm 8 is used by ~3.6 million domains in
    KSKs and ZSKs (a ratio of 50:1 for alg 8 : alg 10).

    And yet, while it is not popular I don't see that any validators
    supporting RSA and SHA256 are at all likely not to support RSA
    and SHA512.  And furthermore, on 64-bit systems SHA512 tends
    to be somewhat faster (more with larger input sizes), because
    it processes input in 64-bit blocks.  On my x86_64 laptop,
    running OpenSSL 1.1.1 beta 'speed -evp', gives:

      type  16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
    sha256 39497.53k   114122.11k   266197.16k   395693.40k   461698.39k  469658.28k
    sha512 30863.64k   122424.60k   278926.37k   495961.09k   643754.67k  654338.73k

    So I am not sure that algorithm 10 warrants discouragement so
    long as 8 is required.  Everyone is going to have both, and
    they're basically the same...  While the case *for* 10 is not
    strong, the case against 10 looks somewhat weak (does supporting
    10 for signing carry a real cost?)

-- 
	Viktor.

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 7 Jun 2018 17:28:03 +0200

> On 7 Jun 2018, at 08:39, Viktor Dukhovni <[email-masked]> wrote:
> 

It is definitely *software* implementors advice.  Good point!

>    10 for signing carry a real cost?)

This particular author believes that the DNSSEC should move to ECC,
so there’s a high cost associated with KSK algorithm rollover. So, if people
are going to change to “stronger” (whatever this means in DNSSEC context)
algorithm they should be strongly encouraged to change the algorithm
to ECDSA256 (for now).

Thanks for the review!
Ondrej
--
Ondřej Surý
[email-masked]

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 7 Jun 2018 17:30:30 +0200

Oh, looking at the text just before the table it says:

        <t>
          Implemenation recommendations for DNSKEY algorithms <xref target="DNSKEY-IANA"/>.
        </t>

I am open to suggestions go to improve this text to emphasize that it is implementation advice,
but apart from typo :), I think it does says “Implementation”...

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

> On 7 Jun 2018, at 17:28, Ondřej Surý <[email-masked]> wrote:
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 7 Jun 2018 11:46:06 -0400

> On Jun 7, 2018, at 11:30 AM, Ondřej Surý <[email-masked]> wrote:
> 
> I am open to suggestions go to improve this text to emphasize that
> it is implementation advice, but apart from typo :), I think it
> does says “Implementation”...

Yes, but the word is somewhat flexible, one might argue that signing
a zone with the algorithm is also a form of "implementation".  So
I would consider: "Software implementation", if that works for the
group.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 7 Jun 2018 14:02:23 -0400 (EDT)

>    Ed25519 seems presently premature.

Unfortunately we had to reduce the complexity of algorithm entries into
the table. My original test used the modifiers common in other WG, and
we could have used MUST on the validation part and SHOULD+ on the
signer part, indicating this is an up and coming algorithm.

But with the limited options we have now, we can only say RECOMMENDED,
because saying "NOT RECOMMENDED" will make people think this algo is bad
instead of thinking "it is a little too soon for this algorithm".

>    and SHA512.

It is not about finding implementations that don't support it. It is
about attempting to reduce a long tail of out of fashion algorithms.
We did a bad a job when adding new ones and we are trying to limit
these for current and future use.

>    And furthermore, on 64-bit systems SHA512 tends

At the time, we were more concerned about packet size than CPU usage.

>    10 for signing carry a real cost?)

I hope it is now clearer why we are doing this?

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 7 Jun 2018 19:33:55 +0000

> At the time, we were more concerned about packet size than CPU usage.

The packet size for RSA algorithms depends only on the modulus,
not the underlying hash function, which just needs to generate
hashes slightly shorter than then modulus.  With RSA keys of 1024
or more bits, SHA256 and SHA512 both fit, and produce signatures
of the same size.

> I hope it is now clearer why we are doing this?

Well, I see that we end up with a bit less code-point diversity,
but in this case 8/10 are barely different and require the same
supporting code.  So while I'm not strongly advocating 10, I see
it just a "tweak" of 8, and would expect to not differentiate
between them, use either, interoperate with neither or both...

Again, this comment is not an objection just saying that I would
have treated 8 and 10 as interchangeable.

-- 
	Viktor.

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 13 Jun 2018 07:27:22 -0400

On 7 June 2018 at 15:33, Viktor Dukhovni <[email-masked]> wrote:

> Except that they are not interchangeable, and algorithm rolls are
operationally expensive.  Anyone doing an algo roll from 8 to 10 is less
likely to want to do one again any time soon. Since there is little gain
from moving to 10, it's better to discourage use of 10 in order to
encourage–and make it easier for–operators to use their algo rolls to move
to ECC instead.