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? -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 >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
