Re: [Add] ADD Requirements Draft

[tirumal reddy <[e-mail]>]

Hi Eric,

Please see inline

On Fri, 28 Aug 2020 at 19:08, Eric Rescorla <[e-mail]> wrote:

>
>
> On Fri, Aug 28, 2020 at 12:35 AM tirumal reddy <[e-mail]> wrote:
>
>> On Thu, 27 Aug 2020 at 18:46, Eric Rescorla <[e-mail]> wrote:
>>
>>>
>>>
>>> On Wed, Aug 26, 2020 at 10:15 PM tirumal reddy <[e-mail]>
>>> wrote:
>>>
>>>> Hi Eric,
>>>>
>>>> Please see inline
>>>>
>>>> On Wed, 26 Aug 2020 at 16:50, Eric Rescorla <[e-mail]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Aug 26, 2020 at 3:10 AM tirumal reddy <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, 25 Aug 2020 at 20:19, Christopher Wood <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks for the review! Please see inline below.
>>>>>>>
>>>>>>> On Sat, Aug 22, 2020, at 2:07 PM, Eric Rescorla wrote:
>>>>>>> > Document: draft-pauly-add-requirements-00.txt
>>>>>>> >
>>>>>>> > Tommy,
>>>>>>> >
>>>>>>> > Thanks for posting this. Two comments on the threat model,
>>>>>>> > requirements, and what mechanisms it leaves in scope. The points
>>>>>>> > below are primarily about local discovery.
>>>>>>> >
>>>>>>> >
>>>>>>> > 1. In S 4, you say you are assuming an RFC 3552 threat model that
>>>>>>> > includes on-path active attackers. However, in S 2.1 you indicate
>>>>>>> that
>>>>>>> > one of the benefits of this type of mechanism is to authenticate
>>>>>>> data
>>>>>>> > coming from the true resolver:
>>>>>>> >
>>>>>>> >    *  Verify that answers come from the selected DNS resolver
>>>>>>> >
>>>>>>> >    *  Authenticate that the DNS resolver is the one provisioned by
>>>>>>> the
>>>>>>> >       network
>>>>>>> >
>>>>>>> > As a side note, I would observe that these benefits derive from the
>>>>>>> > use of an authenticated channel, not from an encrypted channel.
>>>>>>> This
>>>>>>> > is sort of a nit in that modern TLS profiles discourage
>>>>>>> authentication
>>>>>>> > only, but I think it's still worth getting right.
>>>>>>>
>>>>>>> Agreed. Use of “encrypted” was referring to the use of authenticated
>>>>>>> DoH and DoT, but I can see how that’s confusing given that we later mention
>>>>>>> opportunistic encryption (as a contrasting approach).
>>>>>>>
>>>>>>> > More importantly, this is only really true if either (1) the client
>>>>>>> > can accurately determine the nonexistence of a secure resolver or
>>>>>>> (2)
>>>>>>> > the client somehow behaves meaningfully differently in cases where
>>>>>>> > it determines that there is no secure resolver. To lay this out in
>>>>>>> > more detail, assuming that it's possible to determine the identity
>>>>>>> > of a secure resolver if one is present (e.g., by the kind of SPAU
>>>>>>> > mechanism that Chrome uses), then there are three cases:
>>>>>>> >
>>>>>>> > 1. The client connects to a secure resolver
>>>>>>> > 2. No authenticated resolver is present
>>>>>>> > 3. There is an attack
>>>>>>> >
>>>>>>> > While it's straightforward to determine whether one is in case (1),
>>>>>>> > many users will be in case (2) and so as long as the client treats
>>>>>>> > (1), (2), and (3) identically, then this doesn't preclude attack by
>>>>>>> > on-path attackers. Thisisn't a new observation, of course, but I
>>>>>>> think
>>>>>>> > it points to the need to sharpen the requirements and potentially
>>>>>>> > S 4.2 if they are to be useful in the face of the threat model
>>>>>>> > you define.
>>>>>>>
>>>>>>> That’s a good point to raise. If clients don’t treat (3) and (2)
>>>>>>> differently, then the attacker can always win. And right now, given the
>>>>>>> threat model, it’s unclear *if* a client can differentiate between these
>>>>>>> cases. Or to put it differently (and I think this was how you phrased it
>>>>>>> once in the past): the client can’t distinguish between a network with no
>>>>>>> authenticated resolver and an active attack.
>>>>>>>
>>>>>>> Perhaps we need to relax the attacker’s capabilities here? If DoH is
>>>>>>> blocked, then, well, what is a client left to do? Section 4.2 punts that
>>>>>>> problem to the client’s policy, which seems (to me) to be the right way to
>>>>>>> deal with this type of attack.
>>>>>>>
>>>>>>> Perhaps it’s worth clarifying that one of the motivations for these
>>>>>>> requirements (and guidance text) is to allow for incremental improvements.
>>>>>>> For example, opportunistic encrypted DNS may be better than no encryption
>>>>>>> for some clients. Although clients can’t determine if this is an attack or
>>>>>>> not, there’s arguably some benefit to it. Or put differently: the attacker
>>>>>>> may easily win for opportunistic DNS, but there may be cases where the
>>>>>>> attacker loses, and that seems like an improvement.
>>>>>>>
>>>>>>> > 2. S 4 says that attackers must not be able to:
>>>>>>> >
>>>>>>> >    *  Redirect DNS traffic to themselves.
>>>>>>> >
>>>>>>> > If we try to map this onto the various proposed mechanisms, I
>>>>>>> think it
>>>>>>> > has to be softened to say something like "Redirect secure DNS
>>>>>>> traffic
>>>>>>> > to themselves when DNS traffic would not be" (again a 3552 attacker
>>>>>>> > can say whatever they want in DHCP). I think this then precludes
>>>>>>> this
>>>>>>> > mechanism having some kind of indicator of where the secure
>>>>>>> resolver
>>>>>>> > is other than at its own IP.
>>>>>>>
>>>>>>> I think that’s right. None of the current discovery mechanisms work
>>>>>>> well for local discovery when the attacker controls the network, since none
>>>>>>> of the current signals are authenticated.
>>>>>>>
>>>>>>
>>>>>> No, it is possible for the client to defend against an on-path
>>>>>> attacker spoofing/blocking encrypted
>>>>>> DNS server discovery, see
>>>>>> https://tools.ietf.org/html/draft-btw-add-home-08#section-10
>>>>>>
>>>>>
>>>>> You describe three mechanisms. The first two seem to involve some sort
>>>>> of external configuration, and so are not of use in the generic case.
>>>>>
>>>>
>>>> No, only the first mechanism requires external configuration. Please
>>>> clarify why you think the three mechanisms are not generic ?
>>>>
>>>
>>> " Cryptographically assert the DNS server identity to identify the DNS
>>> client is connecting to an encrypted DNS server hosted by a specific
>>> organization"
>>>
>>> The client has no way of knowing what organizations are acceptable.
>>>
>>> The reason these aren't generic is that clients in general will not be
>>> so configured.
>>>
>>
>> I see the confusion, and will fix the text. The intent is to say the
>> cryptographic assertion of the DNS server identity
>> proves to the client the encrypted server is hosted by a legal
>> organization/entity. It prevents the attack scenario where
>> an attacker hosts an encrypted server and claims the best DNS privacy
>> preservation policy.
>>
>> The client can then prompt the user to decide whether the encrypted DNS
>> server hosted by a specific organization is
>> acceptable or not. The resolver information published by the DNS server
>> also includes a privacy statement URL, optional audit URL,
>> whether the DNS server performs filtering and reasons for filtering.
>>
>
> As I said when you first proposed this in an ADD meeting, I do not believe
> that anything of this kind is viable.
>

> 1. Certificates tied to a legal entity have not been effective, which is
> why browsers are removing EV.
>

The draft does not propose using EV certificates for encrypted DNS servers,
please see
https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-05#section-4
for
more details.

2. There is ample evidence that users do not read privacy policies.
>

The DNS server privacy statement is much more simpler compared to a typical
privacy statement by a
content service provider (see
https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-14#section-6).

Further, automated analysis of a privacy statement is possible using deep
learning (https://pribot.org/files/Polisis_USENIX_Security_Paper.pdf). You
can explore polisis and pritbot at https://pribot.org to explore the
analysis of privacy statements by several organizations..


>
>
>>
>>>
>>>
>>>>
>>>>> I do not believe the third, STUN-based mechanism works. The attacker
>>>>> can make the client believe that it has any external IP of its choice by
>>>>> tunnelling the STUN traffic.
>>>>>
>>>>
>>>> Yes, it may be easy for an attacker to identify STUN traffic but
>>>> challenging to identify TURN server running on port 443 (TURN-over-TLS).
>>>>
>>>
>>> Well, it will be public information (because it's embedded in many
>>> clients) where the servers are.
>>>
>>
>> Yes, good point. If many services are hosted on the same IP address, it
>> will be challenging to identify the
>> TURN-over-TLS/STUN-over-TLS session.
>>
>
> They will also have a different ALPN value.
>

Yes but ALPN and SNI can be encrypted using TLS encrypted client hello.
Anyways, the client can also use HTTPS
(similar to https://ipinfo.io/ip-company-api).


>
>
>>
>>>
>>>
>>> Further, an attacker may or may not be always on-path and the client can
>>>> remember that an encrypted resolver is provided by the attached
>>>> network (e.g., associate the domain name/organization hosting the encrypted
>>>> resolver with the SSID:BSSID). If later the endpoint cannot discover the
>>>> network-provided resolver, it can assume an attacker blocked the discovery.
>>>>
>>>
>>> Or that network conditions changed in some way or other, which might
>>> result in unacceptable numbers of false positives.
>>> In any case, this is a weaker threat model than described in the draft.
>>>
>>
>> Agreed, if the client cannot take an action at least it can notify the
>> user that it cannot discover the previously seen
>> network-provided encrypted resolver.
>>
>
> A dialog which the user will see a lot and therefore likely click through.
>

The user should only get a notification if an attacker blocks the discovery
or the home network uses a different ISP that does not host an encrypted
DNS server.

I don't get why the user would get a frequent dialog ?

Cheers,
-Tiru


>
> -Ekr
>
>
>> -Tiru
>>
>>
>>>
>>> -Ekr
>>>
>>>
>>>> -Tiru
>>>>
>>>>
>>>>>
>>>>> -Ekr
>>>>>
>>>>>
>>>>>> -Tiru
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Best,
>>>>>>> Chris
>>>>>>>
>>>>>>> --
>>>>>>> Add mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/add
>>>>>>>
>>>>>> --
>>>>>> Add mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/add
>>>>>>
>>>>>