On Mon, Jul 03, 2023 at 08:25:08PM +0200, Peter Thomassen wrote:
> Now, assume a multi-signer setup of, say, algorithms 7 and 13. This is
> not an uncommon transition (ietf.org did it last month, except that
> they went unsigned). In such a scenario, a resolver on Red Hat would
> only consider the algo 13 DS records.
Yes, the only way to move and stay signed in the case of ietf.org was to
complete a transition to algorithm 13 while still self-hosted, and only
then migrate to Cloudflare's hosting platform (based on the expectation
that Cloudflare don't support signing with algorithm 7).
This IIRC was more complexity than they were willing to take on.
> Under the relaxed RRSIG presence rule, it would be fine to serve
> signatures of *one* algorithm only (either 7 or 13). If only 7 is
> served, my understanding is that this would lead to SERVFAIL, because
> signatures are missing for the only supported algorithm. There is no
> valid path.
The relaxed RRSIG presence rule (for signers) is fundamentally
incompatible with the DNSSEC security model. So long as there exists a
non-negligible population of resolvers that support only one of the two
algorithms, queries for a zone where some or all servers return RRSIGs
for just one of the two algorithms will sporadically fail validation.
And since the whole point of multiple (dual) providers is to be able to
operate in the face of an outage of one of the providers, if the one
that fails is the only one with supported RRSIGs (for a given resolver)
the outage is then total, rather than sporadic.
So long as both providers are up, some queries will randomly find an
acceptable resolver, and caching might then keep the failure rate low,
but note also that not all resolvers try another server when a bogus
response is detected.
Some notable resolvers do "late" validation, where the query with all
necessary referral chasing and retransmissions is performed first, and
the response is validated at the end, with no opportunity to retry the
query at another server. So when the cache is cold, failures will
happen until some query eventually hits a compatible server.
> Here are the questions:
>
> 1.) Is SERVFAIL the correct behavior in the above scenario?
Yes, unless a better server happens to be found (see above). The
response is bogus.
> 2.) Does anyone think that "insecure" is the right behavior? ("I can
> see another signature of algorithm 7 which I can't validate; it might
> match, so I'll pass this.")
Absolutely not. DNSSEC without resistance to active attacks is mere
security theatre. You get all the failure modes, and none of the
protection.
> 3.) If anyone thinks that "insecure" is fine: Why should the resolver
> assume that things are fine, and that the lack of signature is not an
> indication of a downgrade-to-insecure attack?
The question is moot. Anyone who thinks that "insecure" is fine is
sadly quite mistaken.
> 4.) In fact, how would the resolver distinguish this from a
> downgrade-to-insecure attack?
Not possible.
> 5.) If the authoritative server can't know what the resolver supports,
> how could it ever be safe, by not sending RRSIGs for all algorithms,
> to introduce the confusion of question (4)?
The only scenario (difficult to know for sure) under which the RRSIGs
can be partitioned by provider is when both operators and the zone owner
are absolutely sure that effectively all resolvers support both
algorithms and only a negligible population they're willing to let break
do not.
This may be somewhat true at present if the two algorithms are 8 and 13,
which one expects every validating resolver to support. These two
algorithms account for roughly 55% and 45% of all signed zones, and
both are used by major TLDs, ...
So, it may **at this point in time** be possible to have one server
returning algorithm 8 RRSIGs, and another algorithm 13, while the DS
RRSet lists both.
This "happy point time" is a result of both MTI algorithms being widely
used and long established.
There are no other such algorithm pairs, and when, for example,
algorithm 15 finally sees non-trivial adoption, it may not be possible
to split 8/15 or 13/15 across providers for close to a decade.
> (Does the signer know enough about the validator to decide which
> algorithms can be advertised but then their signatures left off,
> because another advertised algorithm is surely supported?)
See above. Perhaps, with luck, at present, when the two algorithms are
8 and 13, but not otherwise.
> Also note that the algorithms in this example (7 and 13) are both
> "MUST implement" on the validator side, RFC 8624 Section 3.1. Some say
> that "MUST implement" is different from "MUST support".
MTI is not a time-invariant fundamental property of an algorithm, and
resolvers of various "vintages" freeze-in different notions of which
algorithms are or aren't MTI. Therefore, MTI does not enter the
equation. Only point-in-time knowledge of the current resolver
population might inform a risk analysis of whether split RRSIGs are
safe.
> 7.) When defining which algorithm(s) to return signatures for, should
> that requirement depend on any "MUST implement" requirements for the
> involved algorithms?
> - If so, why? (Is it practical? See algorithm 7.)
> - If not, why not?
See above, there is no universal consensus on the set of MTI algorithms.
> 8.) If a resolver supports one of the algorithms offered via DS, is it
> correct that (barring CD flag) it MUST NOT, under any circumstances,
> return insecure data?
Yes, otherwise DNSSEC is mere security theatre that offers various
failure modes, but offers no protection against active attacks.
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
