On 24 Jun 2025, at 21:38, Ben Schwartz <[email protected]> wrote:
> 1. An attacker could strip the SVCB record and its RRSIG, resulting in an > ordinary delegation response that would be accepted and used without > encryption. True. A client that didn't find a record could query for it which would give it the ability to validate any non-existence, but that sounds like a lot of pointless queries in the situation where the majority of zones don't have this kind of thing deployed (when most referrals don't include a courtesy SVCB). > 2. This is a child-side record, and so presumably also a child-side RRSIG, > but the validator may not yet have the child's DNSKEYs. Fetching those keys > (in order to validate the transport configuration) would create additional > delay before the query could be sent. That additional delay can be amortised over the lifetime in the cache of those records needed to provide a chain of trust though. A validator is going to have to do that work at some point. > 3. The parent-side logic to serve this RRSIG, and the coordination channels > to get it there, seem complicated. I guess. It seems approximately as complicated as CNAME flattening which is pretty common. > Assuming it is signed by the ZSK, this also breaks a usual rule of not having > parent-side content depend on the child ZSK. The referral can be processed without it (by using other transports) so I'm not sure it's a dependency. The downgrade attack seems worth thinking about. I'm not sure how much we need to care about the other things. Joe
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
