Re: [Doh] Talking to my resolver

[nusenu <[e-mail]>]

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.
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.

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