Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update

[Paul Wouters <[e-mail]>]

On Thu, 2 Mar 2017, Roy Arends wrote:

> Implementer should follow spec. Spec sez MUST or SHOULD.

Implementers may decide to implent some algorithms and not some others,
depending on the level.

> Now it says MUST- MUST+ MUST SHOULD- SHOULD+ and SHOULD. Very confusing.

I understand _you_ find it confusing. It has been used for years in the
ipsec working group without having caused confusion.

> Which one should be implemented?

Saving you the time to re-read Section 1.2 and Section 2:

    SHOULD+   This term means the same as SHOULD.  However, it is likely
              that an algorithm marked as SHOULD+ will be promoted at some
              future time to be a MUST.

    SHOULD-   This term means the same as SHOULD.  However, an algorithm
              marked as SHOULD- may be deprecated to a MAY in a future
              version of this document.
    MUST-     This term means the same as MUST.  However, we expect at
              some point that this algorithm will no longer be a MUST in a
              future document.  Although its status will be determined at
              a later time, it is reasonable to expect that if a future
              revision of a document alters the status of a MUST-
              algorithm, it will remain at least a SHOULD or a SHOULD-.


MUST+ is something you made up, but if you have any divine algorithms
to share, maybe we can do something :P

> How do I add a grade of importance to specific algorithms, while the protocol itself doesn’t care.

I don't understand this remark.

What the + and - symbols are conveying is a likely trend. It is an
effort to ramp up secure algorithms more quickly and to make the long
tail shorter. Without being naive and writing in flag days into RFCs
that implementers are forced to ignore. If we write MUST NOT for SHA1
one, it would be extremely damaging to the current deployment.

You indicated you find this useless. That's fine. If the majority of
the WG agrees with you, we can remove it. I think it will make the
document less informative to implementers.

> DNSSEC has no signalling which algorithm is more or less important in the future.

Which seems to only be a reason in favour of describing this in the RFCs
for implementers?

>> Well, secspider is pretty good?  http://secspider.verisignlabs.com/stats.html
>> 
>> 1,641,133 	Production DNSSEC-enabled zones
>> 
>> RSASHA1-NSEC3-SHA1	1,320,540
>> RSA/MD5			21
>> RSA/SHA-1 [RSASHA1]	123,575
>> RSA/SHA256 [RSASHA256]	2,332,855
>> 
>> Number of keys does not directly map to number of zones (we have 3.6M
>> keys and 1.6M zones) but this shows 1/3 of the keys are still using
>> SHA1.
>
> Okay, so you did make it up.
>
> 1/3 is not 1/2.

There are people willing to break 1/3 of the internet but not willing to
break 1/2 of the internet?

> How many of those SHA1 keys are used in conjunction with non-SHA1? That is, how many would still be secure when SHA1 is ignored?

Yes, it is theoretically possible that the 1.3 million keys with SHA1 that
are currently deployed are in a zone that is currently in the process of
an algorithm rollover with SHA2. Maybe we can ask Geof since secspider
does not log this.

> Again, how many zones does it affect when most of them have SHA2 as well?

"Do you have the data or are you making this up"

> The damage I’m trying to avoid is the false sense of security you are inflicting by not taking the proper action.

The proper action being to make millions of zones lose SHA1 based DNSSEC
protection and leaving them vulnerable to simple DNS spoofing that does
not take 6500 CPU years?

You are afraid this document obsoletes too slowly, yet we have vendors who
says this document is moving way too quickly and they will never ever
remove anything. As an author, it is not my goal to produce a document
that has to be ignored.

> It is because the lack of action from specs like these that BIND-9.11.0 still ships with SHA1 defaults:

Hmm. If you look at algorithm selection in Section 3.1, you can see SHA1
based algorithms listed as MUST- and SHA256 based algorithms listed as
MUST. So our +/- signaling would actually be a great way for
implementers to decide that RSASHA256 is a better default then RSASHA1.

And had we both had to list them as MUST without any qualifier,
implementers wouldn't have been given that guidance.

Paul