On Mon, Nov 26, 2018 at 2:08 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > > On 25/11/2018 17:18, Nick Lamb wrote: > > In section 7.1 the -02 draft says: > > > > Clearly, DNSSEC (if the client validates and hard fails) is a defense > > against this form of attack, but DoH/DPRIVE are also defenses against > > DNS attacks by attackers on the local network, which is a common case > > where SNI. > > > > Where SNI what? > > I'm guessing what's missing is an argument that DoT or DoH can > (if better than opportunistic) counter some local attacks that'd be > similarly mitigated by DNSSEC. > Actually, these local attacks are better mitigated by DoH/DoT, because what you want is to conceal the name you are looking up. -Ekr > I'd be tempted to just say that yes, an active adversary can force you > > to choose between privacy and connectivity, and hard fail DNSSEC is the > > only existing way to choose privacy. > > Perhaps (exceptionally) less so in this case. The client here > depends on confidentiality of the DNS query for both the A/AAAA > and ESNIKeys RR's, so an authenticated DoT or DoH connection > to a chosen recursive could be a pretty good defence here. And > DNSSEC alone (hard fail or not) isn't sufficient. > > > The current text feels more like an attempt by people who don't want to > > face the Dancing Pig problem to justify why their latest seat-belt that > > snaps in a crash (to borrow Adam Langley's phrase) is a good idea > > anyway. But regardless of whether I'm correct about that, the sentence > > is confusing as it stands now. > > FWIW, I'd have no issue with more strongly encouraging DNSSEC, > but I think ESNI turns out to be a situation where the presence > or absence of DNSSEC perhaps makes less difference that in other > TLS cases. For example, I think there's a stronger argument for > DNSSEC being used to secure CAA RRs or those used by any ACME > challenges, than there is for reasons related to ESNI. > > Cheers, > S. > > > > > > Nick. > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
