On Tue, 28 Feb 2017, Paul Hoffman wrote:
The recommendations in the document are completely unclear if it is talking
about:
- what should be in signer implementations
- what should be in validator implementations
That is clearly Section 3 in two seperate columns
- what someone who is starting to sign today SHOULD/MUST use
Obviously pick one of the mandatory-to-implement DNSSEC Signing"
algortihms of Sesction 3. Obviously, picking a MUST over a SHOULD
would be a safer bet.
- what someone who is already signing SHOULD/MUST use
Try to do the same as above, provided their software is fully testing
and can handle algorithm rollovers.
I think those four lists are probably different.
The Signer / Validator column is obviously different, as the validator
needs to deal with the long tail versus insecurity, whereas the signer
software can be a little more aggressive in dropping support for weak
things. I don't see why the recommendation of "already signing" and
"newly signing" should be different, other then "ensure you can do an
algorithm rollover".
Before the document is
picked up by the WG, it would be good if it made clear which lists it is for.
I do not think that is needed.
My personal feeling is that if we do the third, we should say MUST NOT with
any SHA1 algorithm because they're going to get nailed in the future by
people who refuse to validate it. If we do the fourth, I would say SHOULD NOT
use now and SHOULD change within two years (or some moral equivalent of
that).
I don't think adding that much more flavours and granularity brings more
clarity. Heck, someone just said that our + and - symbols was already
too much granularity :P
And then we have some software people who say "we will never remove
anything because that can break our users' scripts".....
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
