On Sat, Nov 2, 2019 at 3:59 PM Eric Rescorla <[email protected]> wrote: > > > > On Sat, Nov 2, 2019 at 11:52 AM Stephen Farrell <[email protected]> > wrote: >> >> >> Hiya, >> >> On 02/11/2019 18:33, Eric Rescorla wrote: >> > On Sat, Nov 2, 2019 at 7:03 AM Paul Hoffman <[email protected]> wrote: >> > >> >> On 11/2/19 9:58 AM, Eric Rescorla wrote: >> >>> Generally, I would expect that a solution which addressed the active >> >> threat model would also address the passive one. >> >> >> >> Of course, but there are many threat models that have different solutions. >> >> The passive threat models might be addressable more quickly than the >> >> active >> >> threat model. >> >> >> > >> > Yes, that's why I asked the question of whether we are trying to solve the >> > active attacker case. >> >> Tackling passive and active attacks are not mutually >> exclusive goals. > > > Nor did I say they were. > > >> >> Experience from SMTP/TLS (as I interpret it anyway) >> was that defence against active attacks only really >> became tractable a few years after mitigations against >> passive attacks had been deployed and clearly hadn't >> broken anything. Note that that transition did not require any changes >> to SMTP/TLS, though it may have needed >> the mail equivalent of HSTS and reporting to have been >> defined (it's hard to tell what really motivated folks >> to try mitigate active attacks for sure). >> >> Whether or not adot is sufficiently similar is (for me) >> an unknown at this point but I'd hope we don't rule that >> out. > > > I think the primary difference between this case and the TLS case, > where, as I note below, defense against active attacks was required from > the beginning, is the question of whether or not the reference that > the initiator has tells it that it supposed to expect security. In the case > of TLS you have that with the different URI scheme (https) but in > the case of email you do not. > > Conversely, what made opportunistic style approaches viable for > SMTP was that there was an existing protocol handshake that > could be conveniently adopted to have upward negotiation (STARTTLS). > This was more of a pain with HTTP, though RFC 2817 does in fact > specify something. > > In this case, I think the relevant question is whether there is some > viable mechanism (by which I mean one that people might actually > use) by which recursive resolvers would, in talking to an authoritative > resolver, detect that that resolver supported secure transport and > upgrade. If there is, then it's potentially possible to have some kind > of opportunistic approach. And conversely, whether it's viable > to have the records that point you to the next authoritative convey > that you should expect security.. If there is, then it's potentially > possible/better to have a non-opportunistic approach
I've suggested a number of times, but haven't actually written up, that you could encode this in the nameserver name - this is somewhat similar to the dnscrypt idea... E.g - no DoX expected: $ dig ns example.com ;; ANSWER SECTION: example.com. 42923 IN NS b.iana-servers.net. example.com. 42923 IN NS a.iana-servers.net. Recursive resolvers should expect DoT: $ dig ns example.com ;; ANSWER SECTION: example.com. 42923 IN NS b-dot.iana-servers.net. example.com. 42923 IN NS a-dot.iana-servers.net. Yes, I'll be the first to admit that it is hacky, and not it's not completely foolproof, but it requires an attacker to do more than just block port 853 to force a downgrade, and also means that resolvers don't have to probe 853, wait for a timeout and then try 53 instead.... W > > >> >> ISTM that requiring day-1 defence against active attacks was to an >> extent responsible for the lack of deployment >> of IPsec and DNSSEC, > > > I don't understand what DNSSEC would do if not defend against active > attack. > > >> so I hope we keep an eye on that >> ball too. > > > OTOH, TLS had day one defense against active attacks. > > -Ekr > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
