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.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. 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
