On Wed, Nov 6, 2019 at 9:31 AM Ted Hardie <[email protected]> wrote:
> In-line. > > On Wed, Nov 6, 2019 at 9:05 AM Brian Dickson < > [email protected]> wrote: > >> >> >> 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. >> > > It seems odd to have the code and operations to do this on both signing > and validation , but then use it intermittently. That seems both hard to > reason about and difficult to explain. > I was interested in Paul's reason for "do not validate", as to whether it was the concerns of generally validating everything, versus having the code and operations that do the validation. I.e., is it the concern about some zones having signing errors, independent from the ADoT thing? More recent operational results have show vastly improved levels of correct operation of DNSSEC, and many fewer problems showing up, although I don't track that myself and don't have references handy. (I think there was a thread recently on one of the relevant lists to that effect, though.) I.e. I don't think aversion to validation generally is rational, but I also don't like all-or-nothing when it comes to validation. I see this as likely being an MTI (mandatory to implement) thing, with knobs to allow operators to disable (against "medical" advice, as it were). > > > >> 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? >> > > I don’t think this would be something to recommend, personally. > Exactly, you have very clearly made my point for me between your two comments. :-) > > Ted > >> >> 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 >> >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
