On Wed, Nov 6, 2019 at 8:21 AM Paul Hoffman <[email protected]> wrote:
> Given that we are (still supposedly) talking about requirements and not > solutions, I would be unhappy with a requirement that prevents a resolver > that is not validating from being able to use encrypted transport to > authoritative servers. Any protocol we develop for ADoT capability > discovery should prevent downgrade attacks but should also work fine for > resolvers that do not validate. > Why? Or rather, let me put together a straw-man to attack. Suppose the requirement (for the protocol for establishing the encrypted transport for actual ADoT or for discovery of ADoT parameters) was that *for this record* the record must be signed and must be validated, but that it placed no broader requirement on validation. I.e. TSLA for cert validation for the TLS connections used, which would require DNSSEC validation (mandatory per DANE RFCs). That would mean resolvers that don't validate *generally*, but do follow the protocol (and validate very specific records) would would fine. Would that be an unhappy-making requirement, or would you be okay with that hair-splitting on validation? Given that presumably *some* changes would need to be made to resolvers for ADoT, IMHO the particulars of *what* changes should all be open to discussion. Brian
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
