Hi Philip,
On 7/25/25 14:22, Philip Homburg wrote:
Why validation does not need special processing for FORMERLY-UNIVERSAL.
The meaning of UNIVERSAL is that signers can mix and match algorithms for
the set of algorithms tagged as UNIVERSAL.
The question then becomes how to remove an algorithm from UNIVERSAL. We cannot
just reclassify an algorithm and expect that over night, zones are signed
with a different algorithm.
So FORMERLY-UNIVERSAL should mean: signers have stop using this as a
UNIVERSAL algorithm as quickly as possible. However for validators, it
still remains mandatory.
This is not the terminology used in the draft:
- UNIVERSAL relates to ubiquitous support in validators;
- FORMERLY-UNIVERSAL relates to formerly ubiquitous support in validators.
Even though algorithm 13 is now UNIVERSAL in that sense, it's entirely possible
for some signer to still use an HSM that only supports algorithm 8, not 13.
Thus, this terminology is *not* about signers here. If you'd like to discuss
general support in signers, let's use different words for that, as to not get
entirely confused.
Now, as for how to handle FORMERLY-UNIVERSAL:
Let's first establish a non-contentious case (which is not affected by the
draft's proposals): If the DS RRset consists of 2 records with distinct
algorithms 13 (ECDSA) and 32 (unknown), and the validator receives a response
with an RRSIG only of algorithm 32, then it will return SERVFAIL. (This is just
for mental context, and obviously not a reasonable multi-signer setup.)
Now let's assume a setup where two providers independently sign a zone (but
serve each other's ZSKs). The domain holder uses this setup so there is no
single dependency on one of them.
The DS RRset may then consist of 2 records relating to distinct UNIVERSAL
algorithms (say 8 and 13), in which case the draft allows the child auth to
serve RRSIGs for only one of them. It is then fine to send a response with
RRSIG for algorithm 8 only. AFAIU you agree with this.
Now presume that eventually, a long time from now, a resolver operator decides
to turn off support for algorithm 8, and then receives a response whose only
RRSIG is with algorithm 8. When treating it as unknown (as in the mental
exercise above), then it will serve SERVFAIL.
As a result, the domain holder is off worse than they would be if they were
with any single of the two providers:
- If they were with just the algorithm-8 provider ("P8"), there would only be an
alg-8 DS record --> insecure
- If they were with just the algorithm-13 provider ("P13"), there'd be only the
alg-13 DS record --> secure
... but in no case would they get SERVFAIL.
It is a quite unexpected result that a domain holder who opts for extra
resiliency by adding a provider will, depending on a validator's arbitrary
decision to turn off support for an algorithm, go SERVFAIL instead of insecure.
There may be various reasons for a validator to turn off support for a certain
algorithm. It may be incompetence, it may be reasons like the ones RedHat had
when breaking algorithms 5 or 7, it may be policy in a certain jurisdiction, we
don't know. But the fact is that it can happen.
Allowing to serve only one RRSIG (of several UNIVERSAL algorithms) unavoidably
leads into this conundrum at the time when a resolver operators phases out an
algorithm.
While signers obviously should soon phase out such algorithms, (1) there's
always a long tail, (2) it's hard to know when a resolver will stop
understanding an algorithm (cf: RedHat), and (3) if you're in single-provider
setup with the phased out algorithm (which as a non-expert you may not know),
and you perform an automatically coordinated (multi-signer) provider change,
then the transition phase will exhibit exactly the same problem.
Thus, this seems to be something to be dealt with.
The way to deal with it is that, in a multi-provider setup, the domain holder
accepts that security properties that any single one provider can guarantee
(i.e., the premise is that whatever guarantees are given can be given by each
provider alone). What does this imply?
If the domain was only with provider P8, then it would be insecure if the
validator no longer supports the algorithm. A multi-signer setup involving
provider P8 therefore cannot give a stronger security guarantee than P8 alone,
which only guarantees insecure responses. Therefore, SERVFAIL is the wrong
conclusion for a P8-P13 joint setup.
The correct conclusion is to treat a zone a insecure when its DS RRset consists
only of (formerly) UNIVERSAL algorithms, where one of them is not supported
anymore by the validator.
As such algorithms are effectively no longer supported everywhere, we need to
signal to signers that they should move away from them. That's why such
algorithms, once known, should quickly loose the UNIVERSAL label. But, they
must be treated differently from an entirely unknown algorithm (see the first
exercise above, with algorithm 32), because their presence justifies treating a
zone as insecure (remember: same guarantees as provider P8 can give alone --
the domain holder approves of this by using this provider as a fallback if
provider P13 fails). We need a designation for this differentiation, hence the
label FORMERLY-UNIVERSAL.
Note that in general, resolvers DO NOT need to implement this. If you continue
to support UNIVERSAL algorithms, or even FORMERLY-UNIVERSAL algorithms, for
that matter, then nothing in the resolver codebase needs to change.
Only if you turn off an algorithm that used to be UNIVERSAL (or official still is, and
its label has not been updated, as in the RedHat case), then validators should remember
that they actual know this algorithm and don't support it (as opposed to "unknown
algorithm"), and treat it as described above.
The implementation effort for this is to keep an array of algorithm numbers
that you don't support, although they were UNIVERSAL at some point.
If you don't turn off algorithm support, then this array is empty / this does
not affect you.
Hope this clarifies it! I agree that the FORMERLY-UNIVERSAL designation is not
exactly beautiful, but we weren't able to come up with a better solution. I'll
be curious to see if anyone has a nicer proposal that still enables serving
just one UNIVERSAL RRSIG without SERVFAIL'ing when a validator loses support
for one of them (for whatever reason). (It's tempting to think that SERVFAIL is
correct here, but remember: if it was a single-provider setup, then the
delegation would be insecure. Adding a provider shouldn't create this failure
mode.)
Best,
Peter
PS: Section 6 (Security Considerations) also explains this. I've written it up
here in new words, perhaps it's more understandable than the draft text ...
An algorithm can remain FORMERLY-UNIVERSAL until we want to make the algorithm
optional.
So in the context of this draft, 5 and 7 should not be FORMERLY-UNIVERSAL.
The first reason is that they never had the qualification UNIVERSAL in
the first place, so there is no need to list them as FORMERLY-UNIVERSAL.
The second is that from a security perspective they are bad enough that
all signers should have moved away already and we cannot rely on wide spread
implentation in validators.
Suppose that in the future we want to get rid of RSASHA2 then we can mark
RSASHA2 as FORMERLY-UNIVERSAL and keep it at that level until we want
drop the requirement for RSASHA2 for validation support.
This does require operators who use this draft to be somewhat agile and
quickly (over a period of years, maybe even a decade) stop using algorithms
that are listed as FORMERLY-UNIVERSAL.
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
Like our community service? 💛
Please consider donating at
https://desec.io/
deSEC e.V.
Möckernstraße 74
10965 Berlin
Germany
Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
