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