On Sat, Nov 2, 2019 at 10:01 PM Eric Rescorla <[email protected]> wrote: > > > On Sat, Nov 2, 2019 at 6:02 PM Warren Kumari <[email protected]> wrote: > >> 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.... >> > > Can you expand on this? Is the convention that if I see x-dot.example.com, > then I should expect DoT? >
Yup, that’s it exactly. As a DNS person, encoding semantics into the name makes me twitch, and I’m concerned we eventually end up with: x-dot-doh-ipv4-and-IPv6-I-also-support-tcp-far-our-in-the-uncharted-backwaters-of-the-western-spiral-arm.example.com, but as a pragmatic and deployment it seem to work. A suitably positioned *active* attacker could probably still cause a downgrade (because glue isn’t signed), but it requires much more work on the attackers part than: deny I do any any 853 permit ip any any This also gives us the opportunity for a bikeshed discussion re: what label to use :-) w > > -Ekr > > >> 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 >> > -- 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
