Re: [DNSOP] draft-arends-dnsop-dnssec-algorithm-update

[Doug Barton <[e-mail]>]

I can't help finding this discussion funny, as I proposed prior to the 
-bis docs that we make RSA-SHA256 mandatory, and SHA1 optional; for the 
simple reason that it was overwhelmingly likely that the root would be 
signed with the former, making it as close to mandatory to implement as 
possible without documenting it as such; and the latter as interesting 
as day-old bread.

Now here we are 13 years later, still having the same discussion, 7 
years after the root was signed with (you guessed it) RSA-SHA256. :)

DNS has a long tail indeed.

On 03/15/2017 10:22 AM, Michael StJohns wrote:
> On 3/15/2017 6:26 AM, Roy Arends wrote:
>> In the spirit of being constructive, we (Jakob Schlyter, Matt Larson
>> and I) have written a small draft
>> (draft-arends-dnsop-dnssec-algorithm-update) that does two things:
>>
>> it changes RSASHA1 from “Must Implement” to “Recommended to
>> Implement”. (RSASHA1 is the only “MUST IMPLEMENT”)
>> it changes RSASHA256 from “Recommended to Implement” to “Must Implement”.
>>
>> The main motivator for this is that implementors have an incentive to
>> move their implementations “default use” away from RSASHA1 (for
>> instance, when a user generates a DNSKEY without specifying an
>> algorithm, or when choosing an algorithm for signing in the presence
>> of more than one algorithm.

FWIW I agree with Roy that we should make 256 a must-implement ASAP 
(since for all practical purposes it is already), and encourage 
implementors in the strongest possible terms to make it the default.

> Must Implement:   RSASHA1 (Until 5/31/2018), RSASHA256 (after 6/1/2018))

Michael, this is pointless, unless you can demonstrate how an existing 
implementation works without being able to use the root key.

> Must Not Implement:  RSASHA1 (After 1/1/2021)
>
> Recommended: RSASHA1 (From 6/1/2018 to 12/31/2020), RSASHA256 (until
> 5/31/2018)

Mostly pointless, although there was an interesting point raised about 
the difference between producing signatures with SHA1, and being able to 
validate them. Telling people that we're creating a long tail by letting 
them continue to use SHA1 for N years will result in a tail of minimum N 
+ 10 years. So telling people to stop using it NOW is the right answer.

I'm torn on how to deal with validation though. "Compliant 
implementations MUST generate a warning when validating signatures with 
algorithms weaker than RSA-SHA56. Compliant implementations MUST 
generate an error for such algorithms starting 4 years from the 
publication of this document as a draft standard, and unless the records 
are signed with a compliant algorithm they should be considered unsigned."

Something like that, although obviously it needs polishing.

Doug