Re: [dns-privacy] [Ext] Threat Model

[Eric Rescorla <[e-mail]>]

On Sat, Nov 2, 2019 at 6:02 PM Warren Kumari <[e-mail]> wrote:

> On Sat, Nov 2, 2019 at 3:59 PM Eric Rescorla <[e-mail]> wrote:
> >
> >
> >
> > On Sat, Nov 2, 2019 at 11:52 AM Stephen Farrell <
> [e-mail]> wrote:
> >>
> >>
> >> Hiya,
> >>
> >> On 02/11/2019 18:33, Eric Rescorla wrote:
> >> > On Sat, Nov 2, 2019 at 7:03 AM Paul Hoffman <[e-mail]>
> 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
> > [e-mail]
> > 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
>