Subject: [Add] ADD WG Github

From: "Deen, Glenn" <[email-masked]>
Date: Fri, 21 Aug 2020 17:50:47 +0000

Hi ADD,

ADD now has a Github presence:    https://github.com/ietf-wg-add

So far it has  just two repositories:
    (1) a generic wg-materials  (not much there yet however)
    (2) draft-add-requirements holding the Requirements doc that Chris Box kicked off on the mailing list right after IETF108.

As with other IETF WG uses of GitHub primary activity and discussion will continue to be on the ADD list while GitHub’s tools can help the groups work such as issue tracking, and the ability to upload materials to help the discussion such as diagrams and drawings.

If ADD document authors and would like an ADD repository for your document please send mail to [email-masked]

This is the first IETF WG Github that I’ve setup and I did my best to follow the IETF-Github drafts but there are still a few things such as how to setup automated activity reports that I’m still not sure how to enable.    Please direct message me, and don’t fill the ADD list, with tweaks and options you’d recommend.

BTW – I believe Chris Box is looking for additional contributors to the requirements doc.

Regards
Glenn Deen, ADD co-chair

---

From: "Chris Box (BT)" <[email-masked]>
Date: Fri, 21 Aug 2020 18:58:27 +0100

> BTW – I believe Chris Box is looking for additional contributors to the

Indeed I am, and also looking for feedback on whether this is a suitable
structure to articulate the initial set of requirements.

Direct links:

https://ietf-wg-add.github.io/draft-add-requirements/draft-add-requirements.html
https://ietf-wg-add.github.io/draft-add-requirements/draft-add-requirements.txt
https://github.com/ietf-wg-add/draft-add-requirements

Hoping to hear your suggestions on the list, the repo, or via any other
means.

Chris

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 21 Aug 2020 13:20:05 -0700

Hello,

Since the requirements item had been discussed, but we hadn’t yet seen document text, some of us have actually written up a draft for the upcoming ADD discussions. This covers:

- Use cases
- Distilled discovery mechanisms (what the use cases can share)
- Security and privacy considerations and threat analysis

https://www.ietf.org/id/draft-pauly-add-requirements-00.html <https://www.ietf.org/id/draft-pauly-add-requirements-00.html>
https://datatracker.ietf.org/doc/draft-pauly-add-requirements/ <https://datatracker.ietf.org/doc/draft-pauly-add-requirements/>

Chris, I think this covers many if not all of the use cases you enumerate. I think it will be critical to include some analysis of what privacy/security guarantees we expect out the discovery mechanism—we tried to base this on the discussion on the list that was titled “My principles for discovery”.

If people agree this is useful content, I’d say we should fold this into the framework you’ve started, and build from there?

Thanks,
Tommy

> On Aug 21, 2020, at 10:58 AM, Chris Box (BT) <[email-masked]> wrote:
> 
> 
>  
> 
> Indeed I am, and also looking for feedback on whether this is a suitable structure to articulate the initial set of requirements.
> 
> Direct links:
> 
> https://ietf-wg-add.github.io/draft-add-requirements/draft-add-requirements.html <https://ietf-wg-add.github.io/draft-add-requirements/draft-add-requirements.html>
> https://ietf-wg-add.github.io/draft-add-requirements/draft-add-requirements.txt <https://ietf-wg-add.github.io/draft-add-requirements/draft-add-requirements.txt>
> https://github.com/ietf-wg-add/draft-add-requirements <https://github.com/ietf-wg-add/draft-add-requirements>
> 
> Hoping to hear your suggestions on the list, the repo, or via any other means.
> 
> Chris
> -- 
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add

---

From: Daniel Migault <[email-masked]>
Date: Fri, 21 Aug 2020 23:16:07 -0400

Hi,

Thanks for initiating the draft. I think that is useful and will provide
more feed backs. That said, with a quick reading, it seems the document is
more focused on use cases that result in a combination of initiation of the
discovery, discovery and selection.
I imagined requirements as a list focused on the discovery protocol. These
requirements could be matched the discovery protocol designed by add. [1]
was an attempt to do that.
I am happy to to publish [1] as a separate draft and improve it in regard
to the use case draft. Just for clarification, I think a use case draft is
important.

Yours,
Daniel

[1] https://tools.ietf.org/html/draft-mglt-add-rdp-02#section-4

On Fri, Aug 21, 2020 at 4:20 PM Tommy Pauly <tpauly=
[email-masked]> wrote:

> Hello,
>
> Since the requirements item had been discussed, but we hadn’t yet seen
> document text, some of us have actually written up a draft for the upcoming
> ADD discussions. This covers:
>
> - Use cases
> https://www.ietf.org/id/draft-pauly-add-requirements-00.html
> https://datatracker.ietf.org/doc/draft-pauly-add-requirements/
>
> Chris, I think this covers many if not all of the use cases you enumerate.
> I think it will be critical to include some analysis of what
> privacy/security guarantees we expect out the discovery mechanism—we tried
> to base this on the discussion on the list that was titled “My principles
> for discovery”.
>
> If people agree this is useful content, I’d say we should fold this into
> the framework you’ve started, and build from there?
>
> Thanks,
> Tommy
>
>

-- 
Daniel Migault
Ericsson

---

From: "Chris Box (BT)" <[email-masked]>
Date: Sat, 22 Aug 2020 08:50:13 +0100

Tommy, (+ co-authors)

That’s a fantastic start. You’ve approached it from a slightly different
direction but it’s also more complete, and consistent. The text can
definitely be folded in.

Daniel,

Could your desire for a single list of requirements be met by the
“Requirement Summary” section of
https://github.com/ietf-wg-add/draft-add-requirements/blob/master/draft-add-requirements.md
? (Once suitably populated)

Thanks
Chris

---

From: Daniel Migault <[email-masked]>
Date: Sat, 22 Aug 2020 10:37:19 -0400

Hi,

> ? (Once suitably populated)
<mglt>
sure. I will send a PR so there is a starting list for discussion.
</mglt>

>> Chris, I think this covers many if not all of the use cases you
>> enumerate. I think it will be critical to include some analysis of what

-- 
Daniel Migault
Ericsson

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 22 Aug 2020 14:07:07 -0700

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.

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.

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.

-Ekr

---

From: "Chris Box (BT)" <[email-masked]>
Date: Mon, 24 Aug 2020 17:33:04 +0100

Tommy,

Here's how I propose to map the content in your draft into the working
group's draft. I'd appreciate comments from anyone on whether this looks
about right. If it is, I'm happy to do the work tomorrow, or if someone
wants to create the pull request that'd be great too.

draft-pauly-add-requirements draft-add-requirements
Take content from Merge into
1. Introduction 1. Introduction
 2.1. Network-provisioned resolvers   3.1. Discover resolvers associated
with one declared by an attached network
 2.2. Client-selected resolvers   3.2. Discover resolvers associated with a
manually-configured resolver
 2.3. VPN resolvers   3.3. Discover resolvers associated with a
VPN-configured resolver
 2.4. Encrypted resolvers for private names   4.1. Discover a mapping
between a locally-hosted domain and a resolver, and 4.1.3. Private
enterprise names
 2.5. Encrypted resolvers for local or home content   4.1.1. Walled garden
content
 2.6. Encrypted resolvers for content providers   4.2. Discover a mapping
between a public domain and a resolver
 3. Discovery mechanisms  Partly covered by the splitting of this draft
into section 3 (Discovery of associated resolvers) and 4 (Discovery of
limited domain resolvers). Content could be copied into the beginning of
both of these.
4. Privacy and security requirements New section prior to 5. Requirements
Summary, so that these requirements can be populated into the summary.
Maybe we then don't need the existing "Security Considerations" section?

One thing I do notice is that your section titles are more human-friendly,
so we could also consider similar titles in draft-add-requirements.

Thanks
Chris

P.S. Still seeking additional authors, so please contact me directly if
you're willing to be such. I could do with *at least* one author from
draft-pauly-add-requirements. (Tommy, Eric, Chris, Patrick, Tommy)

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 25 Aug 2020 07:48:36 -0700

Thanks for the review! Please see inline below.

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

> S 4.2 if they are to be useful in the face of the threat model

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.

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

Best,
Chris

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 25 Aug 2020 08:35:38 -0700

On Tue, Aug 25, 2020 at 7:49 AM Christopher Wood <[email-masked]>
wrote:

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

Yes, I think that's a good idea. For instance, one could look at cases
where the attacker is read-only or where the attacker controls your uplink
but not your local network.

-Ekr

---

From: tirumal reddy <[email-masked]>
Date: Wed, 26 Aug 2020 15:39:58 +0530

On Tue, 25 Aug 2020 at 20:19, Christopher Wood <[email-masked]> wrote:

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

-Tiru

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 26 Aug 2020 04:19:59 -0700

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

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.

-Ekr

---

From: tirumal reddy <[email-masked]>
Date: Thu, 27 Aug 2020 10:44:47 +0530

Hi Eric,

Please see inline

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

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

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.

-Tiru

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Aug 2020 06:15:53 -0700

On Wed, Aug 26, 2020 at 10:15 PM tirumal reddy <[email-masked]> wrote:

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

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

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

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

-Ekr

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 27 Aug 2020 07:52:10 -0700

On Thu, Aug 27, 2020, at 6:15 AM, Eric Rescorla wrote:
> >>> 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 ?
> 
> The reason these aren't generic is that clients in general will not be 
> so configured. 
> >  
> >> 
> >> 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.
> 
> 
> > 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. 

Indeed. And it seems useful to ask whether or not this weaker threat model, for local discovery, is realistic, or if we're just moving the goal post to build a protocol that works. 

Best,
Chris

---

From: tirumal reddy <[email-masked]>
Date: Fri, 28 Aug 2020 13:05:13 +0530

On Thu, 27 Aug 2020 at 18:46, Eric Rescorla <[email-masked]> wrote:

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

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.

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

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

-Tiru

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Aug 2020 06:38:14 -0700

> 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.
2. There is ample evidence that users do not read privacy policies.

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

They will also have a different ALPN value.

> Agreed, if the client cannot take an action at least it can notify the
> user that it cannot discover the previously seen

A dialog which the user will see a lot and therefore likely click through.

-Ekr