Rephrase security rules in terms of authentication

[bemasc]

No description provided.

[mstojens]

Love the additional considerations, the more clarity we can give about the edge case nuance, the better.

Why are you taking us back to resolver.arpa at all? Given the caveats, why not let the client trust the name where it can then treat this as the same code path as starting with a name non-DDR discovered? Maintaining resolver.arpa seems like unnecessary complication when we're gaining consensus on "we should not try to add technical security mechanisms to address DDR case". It also complicates your added security considerations logic (only a subset of the three authenticated conditions apply).

Can you please split your added security discussion about what makes RESINFO authenticated (independent of discovery mechanism) and yoru proposeal that we use resolver.arpa with DDR IP discovered resolvers?

[bemasc]

Why are you taking us back to resolver.arpa at all? Given the caveats, why not let the client trust the name where it can then treat this as the same code path as starting with a name non-DDR discovered?

It sounds like you're thinking of an alternative where we apply the same authentication rules but look for RESINFO on the SVCB TargetName instead of resolver.arpa. I think that would not be as good a solution:

1. It is not secure for non-DDR-aware resolvers under this draft's current authentication rules, which assume that the RESINFO QNAME is trustworthy. The attacker could inject a SVCB record whose TargetName is a DNSSEC-signed domain that they control.
2. It is not compatible with services that want to share a TargetName among many distinct resolvers, distinguished by DoH path or port number. (NextDNS runs a similar arrangement today.)

It also complicates your added security considerations logic (only a subset of the three authenticated conditions apply).

Validation options 2 and 3 require the name to be DNSSEC-signed, and for there to be a secure validation path available. Both of these conditions are usually false, so Option 1 is usually the only one available. "resolver.arpa is unsigned" doesn't seem like much of a special case.

We could remove those options entirely, but they do seem useful for the case of querying RESINFO about other resolvers ... at least in some hypothetical future where most resolver names are signed.

Can you please split your added security discussion about what makes RESINFO authenticated (independent of discovery mechanism) and yoru proposeal that we use resolver.arpa with DDR IP discovered resolvers?

I don't think it's separable. The current draft has its rules for authentications (based on "sig"), #14 has its own rules for authentication (based on checking the resolver's certificate against the RESINFO owner name), and this PR has its rules (based on cache poisoning resistance).