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

[Michael StJohns <[e-mail]>]

On 3/16/2017 12:38 AM, Doug Barton wrote:
> 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. :)

Hi Doug -

I don't disagree.  But part of the problem is that there are probably 
zones that are only signed with SHA1.   There ought to be a second 
document that says "Signing with SHA1 ends on this date", but that can't 
be done as a registry update AFAICT.    What can be done is sort of give 
the hint to the implementers that there's a transition in progress and 
that the MTI will be changing, and that the current MTI is going away.

In any event, this (my note) was a procedural suggestion that *_we 
generally don't do operationally critical changes to code without some 
warnings to the community_*.  While most folk knew this was coming - 
until its a "standard", many will not care. Once it's a standard, not 
doing the change becomes costly in terms of liability.

We're (the community/ICANN) in the process of doing a root key change 
for the first time ever - the notices and planning on that took years.  
Giving some notice that the MTI for signing is changing before actually 
changing the implementation guidance seems useful.

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

Fair enough.  But again, this isn't completely about the implementation, 
it's about the operation even though this document will only directly 
affect the implementation.

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

This guidance applies both to the server side and client side.  The idea 
here is that as of 6/1/2018 no one should be able to count on a client 
being able to validate SHA1 (and zones shouldn't be signed with it, but 
could be for legacy reasons), and that after 1/1/2021 the chances of a 
zone signed with SHA1 being able to be validated go down quickly and 
that zones must not be signed with it.

Sorry - I look at this the same way I looked at building 5011.   The 
servers and clients are very loosely coupled - so loosely coupled that 
the servers are sending data to the clients fairly blindly without any 
real knowledge of what they can understand in terms of the data 
content.  (EDNS gives you information on  DNS transport, not DNS data).  
So providing implementation guidance has to understand that split, has 
to understand that when you move Required to Recommended and Recommend 
to Required some implementers will only implement the new required, and 
that the implementers of the clients may not be in sync with the 
implementers of the servers leading to disconnects.

If you want to add SHA256 as a Required immediately, I have no issues 
with that (and you are correct in that that should have been done years 
ago), but I would object to removing SHA1 as a required without a 
deprecation phase for the reasons above.   I'd also *really* like to 
have a final phase out date for SHA1 as well.

If DNSOP instead issues an operational guidance document to be released 
in conjunction with this algorithm update explaining when the zones 
should stop signing with SHA1, I think *that* would be the best of both 
worlds.

Mike



>
> 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
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop