On Wed, 21 May 2025, Wes Hardaker wrote:
I have some questions I would like to see a short discussion on before
balloting Yes
The columns added to the IANA "DNS Security Algorithm Numbers"
[DNSKEY-IANA]
While doing IANA updates, can this document perhaps also update the name "DNS
Security
Algorithm Numbers" because it is very confusing. It is only the DNSKEY
algorithm numbers,
used in some other records too (eg RRSIG). But there are other algorithm
numbers in DNSSEC
too, and which are not covered by this one (eg DS algorithm numbers).
Perhaps "DNS Signature Algorithm Numbers" ?
Though I understand the point, I really really don't think such a change
should be made in this document. We've tried to make this document
focus only on the task at hand, and that's throwing a whole other goal
at the document that hasn't had any community discussion.
I understand. I was just thinking DNSOP doesn't often update IANA
registries, so if we don't sneak it in now, it won't happen. But I
wanted the discussion to be had, it is not a blocker for me.
[but I do agree that the two tables are rather confusing... The number
of times Warren and I have had to consult the tables and re-learn how
they actually work has probably grown beyond counting on two hands at
this point]
Then maybe do a quick check with the WG to do it? If the experts get
confused, what about DNS adjacent people?
RECOMMENDED / MUST / MAY
I wonder why the document uses the levels RECOMMENDED with MAY and MUST,
instead of either
MAY/SHOULD/MUST or RECOMMENDED/NOT RECOMMENDED/MAY.
The WG had a discussion about the right wording to use, and this was the
consensus selected.
I know. I took part in it at some point. Again, I just wanted the
discussion and it is not a blocker.
Validating recursive resolvers are encouraged to retain support
for all algorithms not marked as MUST NOT.
Why "encouraged"? This is a perfect spot to use SHOULD or RECOMMENDED, since
it is aimed at implementers of resolvers.
Because some of them are MAYs and I don't think you should say SHOULD
support a MAY.
But your point is valid. It's also confusing because of the word
"retain". I'm actually thinking that sentence should go away as I'm not
sure it adds anything that aren't already in the recommendations table.
Thoughts?
I'd be okay with removing it completely.
When there are multiple RECOMMENDED algorithms in the "use"
column, operators should choose the best algorithm according to
local policy.
This reads weird. An operator for a resolver has no real choices for
selecting the best algorithm - the algorithm is set by zone owner, not
the operator of the resolver. I think this sentence should be rewritten
to be signer specific (and publisher specific for DS in the next section),
and a new sentence for resolvers should be added to say something.
Validators also get to pick which algorithms they support vs considering
anything else to fall into an insecure tree.
That's a weird way to say they have a choice. The sentence reads as if
there is a crypto negotiation happening about algorithms to choose from.
Hoe about removing "best", eg "choose the algorithms according to local
policy" ?
It seems the section on Operational Considerations has nothing to do with
this document, as this document doesn't handle algorithm rollovers at all?
Well, the document does talk about standardization levels and thus hints
at "times are not static forever" and offers guidance for when levels do
change (and the table is thus updated).
Is it directly reflecting the point of the draft? you're probably
right, no.
Is it helpful to the reader anyway? probably
Is it harmful to have in there? probably not
I think it adds confusion to the non-expert reader. Now they think they
need to both configure their resolvers AND do something with
"rollovers". As I said in my ballot for the "no SHA1", it fits there
much better (but is absent there).
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Implementations need to be conservative in the selection
of algorithms they implement in order to minimize both code
complexity and the attack surface.
I don't think this is particularly true or relevant. The real issue is that DNS
has a long tail and it becomes very difficult to remove old algorithms, so
introducing new ones should be done with constraint.
Minimizing code complexity and attack surface are definitely factors in
implementations that I'm aware of (DNS or otherwise).
Most complexity is in the crypto libraries that support these anyway.
The DNS library mostly just switch()es on it :P Also the "conservative"
could mean "only do the RECOMMENDED", which means you would never get to
promote from MAY to RECOMMENDED because you are waiting for the world to
be ready before you recommend. So in a way, this statement puts a break
on adding new algorithms.
Though adding
text based on your other comment is possible. Maybe: "Deployed algorithm usage
in DNSSEC does not change quickly, and thus constraint should be used
when adding new algorithms"?
Sure.
The perspective of implementers may differ from that of an
operator who wishes to deploy and configure DNSSEC with only
the safest algorithm.
I think this mixes up implementers/operators with the actual real difference
of resolvers/signers. Signers wish to use the best ones, but resolvers need
to handle older/worse stuff as well.
This text is discussion implementation vs operations, but your text is
only about operations (signing vs validation) and thus different in
nature. If anything, we could talk about both but I think the current
statement concept is still needed.
But "only with the safest" is weird, since not supporting some makes
those guaranteed "more unsafe" as they are being ignored and the sign
practically goes unsigned and ready to spoof.
Since the effect of using an unknown DNSKEY algorithm is that
the zone is treated as insecure
I would use "unsigned" instead of "insecure" here.
Maybe: "as unsigned, which results in an insecure delegation"?
I guess it really depends on your target group. I prefer mine strongly
but will take yours.
Paul
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
