Re: [Doh] security goals

[nusenu <[e-mail]>]

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

that is the current status quo with no specification that defines
DoT discovery mechanisms (or is it?). In an I-D I'd include:

- a mechanism that does not force the operator to use the same IP for Do53 and DoT 
(other than just for the initial discovery mechanism)
- allows multiple DoT endpoints for increased redundancy
- allows the Do53 resolver operator to support DoT without running DoT
servers themselves
- running DoT on non-853 ports (i.e. 443)
 
>> 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?

Good point, lets define a threat model first:

Consider an adversary that has the following capabilities:

- can manipulate and read any network traffic from the user (including DHCP)

- the adversary's capabilities are limited to some networks
(i.e. public wifis) but he has no global capabilities

- the attacker can _not_ issue trusted certificates for arbitrary IP addresses
- the adversary has _no_ access to the client system
 
security goals:
if the victim uses DHCP for Do53 discovery:
 - prevent attacks that impact the victim's DoH server URI
beyond the visit in an adversary-controlled network (i.e. public wifis)

if the client is configured to use a static Do53 server (no DHCP for DNS server discovery used):
 - prevent the adversary from feeding the victim with his DoH URI
 - prevent a silent downgrade attack that makes the victim believe
a previously discovered DoH server does no longer speak DoH (to force the victim to plain Do53)

As outlined in [1] I believe these goals are currently not met yet and an adversary can feed a victim
his DoH server URI even beyond the victim's visit in the adversary controlled network.
It would be great if we could improve this (I think we can).

kind regards,
nusenu


[1] https://mailarchive.ietf.org/arch/msg/doh/295yrI72xt0eSnYueiOuqVpSj4s


-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu