Re: [Doh] Talking to my resolver

[Ben Schwartz <[e-mail]>]

On Mon, Mar 18, 2019 at 5:36 PM nusenu <[e-mail]> wrote:

> Martin Thomson:
> >>> But why not provide a mechanism that can do for DoT what this
> >>> does for DoH?
> >>
> >> I'd like to see that happen as well but I assume that will not be
> >> on the DoH WG since it is outside it's charter?
> >
> > I'd hate for our charter to cause us to disregard better solutions.
>
> These are encouraging words. I'd support the inclusion of a DoT
> discovery mechanisms if that is asked but I assume a discovery mechanism
> for DoT will be specified anyway, if not in this one it will be in a
> separate document.
>

DoT is currently discovered by probing port 853 on the resolver's IP
address.  Is this sufficient for your use case?


> One reason that makes me think it would be worthwhile to have a
> single document for both (DoT and DoH) is that we might end up
> with a better protocol.
>
>
> I'm taking a step back and ask two high level questions
> and answer them for myself but it would be great to hear more
> opinions.
>
> What use-cases are we aiming to cover?
>
> I assume the primary use-case here is
> "Application (or OS) wants to discover a DoH server associated with the
> current Do53 resolver".
> (also but to a less extend "web application wants to discover ...")
>
> What security properties are we aiming for?
>
> I'd like to see a protocol that is not vulnerable to man-in-the-middle
> and downgrade attacks, even if that means that use-cases that can't
> detect the IP address of the currently used resolver can not be covered.
>

An active adversary "in the middle" can fully substitute itself for a Do53
resolver without alerting the user.  Do you see an achievable defense
against downgrade attacks, or is this not part of your threat model?

Alternatively we could have a 'strict' and an 'opportunistic' discovery
> profile
> with distinct security properties to tackle all currently covered
> use-cases without weakening the security properties of the entire protocol
> for all use-cases?
> (example: "A client able to determine the resolver's IP address MUST NOT
> use the
> "DoH Servers from DNS" discovery mechanism.")
> At the very least we should prevent a temporary on-path attacker getting a
> persistent
> feed of a victim's DoH traffic as described in my other email [1].
>
> [1] https://mailarchive.ietf.org/arch/msg/doh/295yrI72xt0eSnYueiOuqVpSj4s
>
> kind regards,
> nusenu
>
>
> --
> https://twitter.com/nusenu_
> https://mastodon.social/@nusenu
>
> _______________________________________________
> Doh mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh
>