Subject: [Add] New Threats ID for ADD

From: "Deen, Glenn" <[email-masked]>
Date: Tue, 21 Jul 2020 00:40:27 +0000

Hi ADD,

I wanted to bring to your attention a short, very short, draft that I wrote up based on an email thread on the WG list.  It captures a basic framework of Green-Yellow-Red threat and trust relationships the user may have with their network.   The hope is that this can be a basis for focusing discussion of threats and what mitigations maybe needed in different situations.

https://datatracker.ietf.org/doc/html/draft-deen-add-threats-00

It is by no means complete, and has one glaring typo in the title which I will fix once the datatracker opens for new version uploads.  Comments on list please.

Regards
Glenn

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 21 Jul 2020 19:26:52 +1000

> https://datatracker.ietf.org/doc/html/draft-deen-add-threats-00

Hi Glenn,

This is an interesting take on the problem.  How do you anticipate identifying networks, or is that left as an exercise for the reader?  One of the things we have struggled with in general is network identification.  And even that falls short of what Green would seem to demand, which is network authentication.

I know that there are some EAP methods that integrate network authentication and therefore might allow for making this call, but I don't know how portable those approaches are.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 21 Jul 2020 11:52:40 +0200

On Tue, Jul 21, 2020 at 12:40:27AM +0000,
 Deen, Glenn <[email-masked]> wrote 
 a message of 102 lines which said:

> I wanted to bring to your attention a short, very short, draft that
> I wrote up based on an email thread on the WG list.  It captures a
> basic framework of Green-Yellow-Red threat and trust relationships
> the user may have with their network.  The hope is that this can be
> a basis for focusing discussion of threats and what mitigations
> maybe needed in different situations.
> 

I see no use for this document. It seems to consider only the
potential risks by outsiders, and not the risks by the operators,
which are as important. For instance, assessing that the "User's ISP
network" is safe or not is not just a matter of wether it is properly
secured: it is also a matter of what they decide to do (an ISP
resolver which censors Sci-Hub is not safe for me, even if it is
secured and protected from outside attackers).

This draft is not a proper threat model for the Internet.

Also, how was decided the list of examples? "User's own home network"
is marked as green but it is typically quite unsafe, both because
typical users do not have the knowledge, inclination and/or time to
secure it, and also because the danger can be inside (see this
excellent paper for many examples
<https://www.schneier.com/academic/paperfiles/Privacy_Threats_in_Intimate_Relationships.pdf>)

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Jul 2020 11:42:37 -0400

Deen, Glenn <[email-masked]> wrote:
    > I wanted to bring to your attention a short, very short, draft that I
    > wrote up based on an email thread on the WG list.  It captures a basic
    > framework of Green-Yellow-Red threat and trust relationships the user
    > may have with their network.   The hope is that this can be a basis for
    > focusing discussion of threats and what mitigations maybe needed in
    > different situations.

I feel that the title:
    _Adaptive DNS Discovery Threats Here_

is trying to do something cute by having "Here" at the end, but I don't know
what it is.  Maybe it's just a typo?

First, I disagree with your Yellow list, a number of things I'd put into the
Red zone.
I think that Airport and Cafe networks may be even more hostile than Hostile Regimes.
But, I think that ultimately, it's up to the end user and their OS to figure
this out.

(Windows already asks this question for new networks, so that's basically
done. We just need to have extended-POSIX APIs that would allow browsers to
determine this)

I would rework these categories a bit.
The key thing is whether or not the end user is aware of the risk.
That is, knowledge that one is on a Hostile Regime network may cause the user
to be more cautious in their use than being on a "Yellow" Hotel network which
is in fact compromised.
Or worse, on a home network which is completely compromised, and the user has
been trained to click through all the https warnings on 192.168.1.x addresses.

Stephane Bortman's criticism is valid, if this were a categorization of the
security of the *networks*, but it's not intended. It's intended, think, as
feedback to the user as to *their* risk of privacy disclosure through DNS
snooping.

Richard Barnes' anticipated my suggestion with the question: how do we tell?
Well, we have RFC3118.
Servers can sign their offers.  They can do this with raw public keys.   Or SEND for RAs.
For WIFI, it can also all be tied into the L2 keys.

It would be worth expanding this ID better to explain these things.

Historically, this was considered useless, but it does allow clients to
recognize servers on a TOFU basis!

RFC3118 does define an assymmetric key mechanism, but the FreeS/WAN/wavesec
team did this ~15 years ago.
  http://web.archive.org/web/20050206050646/http://www.wavesec.net/
hmm. Not all the details of the RFC3118 signature is there. I can dig stuff
up.

We never were able to deploy our signed version for reasons involving getting
certain pieces of, at the time unmaintained, DHCP code upstreamed.

RFC3118 was created in the best of IETF tradition:
   Jeff Schiller and Christian Huitema developed the original version of
   this authentication protocol in a terminal room BOF at the Dallas
   IETF meeting, December 1995.  One of the editors (Droms) transcribed
   the notes from that discussion, which form the basis for this
   document.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Deen, Glenn" <[email-masked]>
Date: Tue, 21 Jul 2020 22:09:06 +0000

On 7/21/20, 2:27 AM, "Add on behalf of Martin Thomson" <[email-masked] on behalf of [email-masked]> wrote:

    On Tue, Jul 21, 2020, at 10:40, Deen, Glenn wrote:
    > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-deen-add-threats-00__;!!PIZeeW5wscynRQ!9otDsu85ylvo5y7L9-JVnWWeCf8M28TWigWZlhsyYmOMKem1Jehj-yHexVGjyJH7$

    Hi Glenn,

The basic heart of the proposal is that it's user centric; The user makes subjective classifications of their edge network based on their own understanding and perspective.  So identification is a challenge that is going to need to involve the user's choice.

My thinking was that we'd use the three classifications as a framing to discuss what mitigations could be defined to deal with the 3 threat/trust levels.   Users would then be able to avail themselves of the appropriate mitigations for trust/threat level they believe they are in.  The classifications examples were not meant to be strictly proscriptive, meaning that while many users even today do happy trust their ISP CPE device and everything behind it on their home network, there are others who don’t and take other measures to protect their home network and devices.  Both are fine and the IETF isn't in the business of telling either situation that they are wrong, but we are in the business of designing things that fit into a variety of scenarios - albeit with different configurations and threat mitigations.

The hope for the proposed classifications is that they will let us productively focus our discussions.     We can even expand the list if needed, but the 3 groupings matches pretty well with how people interact with the real world threat levels:   (1) what you believe you can trust; (2) what you think you likely should be able to trust; (3) what you know you can't trust.  Where any particular thing falls into is both subjective and open for revaluation if conditions or perceptions change, but the 3 buckets is a pretty good classification in classic threat analysis.

 I'm not proposing a formal method for a network segment to be labeled greed/yellow/red - but I do think as we work through our collective thinking on what's needed and what's good enough in each zone it will help us come to a good place where the discovery and resolver info methods will meet with both the need of the user to connect successfully to a encrypted DNS resolver, but also enable them to do so with appropriate protections.

-glenn

---

From: "Deen, Glenn" <[email-masked]>
Date: Wed, 22 Jul 2020 01:17:46 +0000

On 7/21/20, 8:43 AM, "Michael Richardson" <[email-masked]> wrote:

    I feel that the title:

Just a typo - will be fixed in the next revision.

I 100% agree that it's the user's choice. The list is a non-proscriptive example and where things fall will change depending on the user's views.    I'll try to make that point in a future draft.

I agree that it's entirely dependent on the user knowing the risk or not.   This isn't too far off non-network risk evaluation and risk taking.    Some 50 yr olds decide to ride the skate board down the sloped street and succeed in making it successfully.   Other decice to ride and fail, sometimes on a youtube video so we all can share the pain and joy.  While others may evaluate the risk and decide not to even give it a try.

Yes.  Both the risk of privacy but also the risk of being sent to a DNS resolver that doesn't behave like they expect.  That expectation could include the behavior that the resolver won't send them to malware sites, or other types of "protect me from bad stuff please" filtering.   Conversely, the expectation may be that the behavior is that the pointed to DNS server applies no filters and just returns everything.     Ultimately it comes down to giving the user what they want and what they expect.

This ID is intended to be used in other drafts that could talk about such things in the actual context of the particular draft.   I wrote it because there was a lot of different what-if scenarios being thrown around and people on occasion where talking across one another and focusing on different sorts of scenarios.   A classic version of this is someone talking about the mitigations appropriate in a red environment where the other person is talking about what is appropriate in a green environment.      It's not unlike what one commonly sees on  tourism forums where an alarmist person posts that everyone must have the latest rip-stop and pick pocket proof backpacks when riding the Metro in Paris. The real answer depends on if the person riding the Metro perceives the Metro as a Green, Yellow, or Red threat level because it's a subjective evaluation by the rider of how they perceive the Metro.   Many many people ride it every day viewing it as a Green level and have no problems, while others may view it as Yellow and others view it as Red.

-glenn

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 22 Jul 2020 06:40:29 +0000

In-line.

> This draft is not a proper threat model for the Internet.

I don't want to shoot down this work but categorization of networks into 
red/green/yellow baskets is hard (if not impossible) and it will lead to 
a very long thread with counter examples. For example:

- Many school and university networks use eduroam with EAP. They should 
be in the green basket.

- Many home networks broadcast a Guest SSID which can be an entry point 
for rogue actors. They should be in the yellow basket.

- Conference networks at security conferences (such as BlackHat, CCS 
etc.) should be in the red basket.

I think discussion on this sort of categorization may not be very 
productive for the working group.

--Mohit

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 22 Jul 2020 06:40:37 +0000

In-line.

> I know that there are some EAP methods that integrate network authentication and therefore might allow for making this call, but I don't know how portable those approaches are.

Some? A bit more than 50 right now 
(https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-numbers-4). 
So you can choose any type of credentials: certificates, passwords, 
PSKs, PAKEs, SIM cards, one time passwords, and various combinations: 
TLS authentication of server and password/PSK authentication inside. 
Admittedly, setting up an EAP network with a AAA server can be 
challenging for many home users but I would rather solve that problem 
than invent a new protocol for doing what EAP does.

--Mohit

---

From: tirumal reddy <[email-masked]>
Date: Wed, 22 Jul 2020 17:26:24 +0530

On Wed, 22 Jul 2020 at 12:10, Mohit Sethi M <mohit.m.sethi=
[email-masked]> wrote:

> > This is an interesting take on the problem.  How do you anticipate
> identifying networks, or is that left as an exercise for the reader?  One
> of the things we have struggled with in general is network identification.
> And even that falls short of what Green would seem to demand, which is
> network authentication.
> >
> > I know that there are some EAP methods that integrate network
> authentication and therefore might allow for making this call, but I don't
> know how portable those approaches are.
>
> (
> https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-numbers-4).
>

It is possible to run AAA server on a home router (see
https://openwrt.org/docs/guide-user/network/wifi/freeradius). I could run
EAP-pwd on home routers to avoid the problems with shared password,
identifying devices using MAC address and the problems with WPA2/WPA3. The
main problem is several consumer IoT devices do not yet support any of the
EAP methods.

-Tiru

>
> --Mohit
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: "Chris Box (BT)" <[email-masked]>
Date: Wed, 22 Jul 2020 14:16:47 +0100

Mohit,

> a very long thread with counter examples.
>

Rather than a hard classification of network X should always be color Y, in
this list I think Glenn clarified it should be like the Windows model, i.e.
when the user first connects to a network, the user is prompted to decide
which trust level (color) it should be. They do this based on their own
understanding of the context.

With that in mind, do you still have an objection? I think the
classifications would be useful for other drafts.

Chris

---

From: Eric Orth <[email-masked]>
Date: Wed, 22 Jul 2020 11:50:18 -0400

Any hard classification of different networks would likely go way too far
into policy controversy.  Since it sounds like the goal is only to loosely
define the categories for discussion purposes, I think the draft needs a
bit more clarification around that.  Maybe a bit of explanatory text to
make clear that different people could trust different networks
differently.  And the "Examples of [X] Networks" labels as-is certainly
imply that those examples are classified as such, so maybe it should be
changed to something like "Examples that a typical user may consider to be
[X] networks".  Maybe some text specifically pointing out when some of
those examples may be in higher risk categories for some users, maybe
something like "ISP networks may be Yellow networks for users that, despite
the contractual relationship, do not generally trust their ISP".

And I'm curious about the intent for how this will be used.  How is this
expected to be helpful in discussions or drafts? Seems we lose a lot of the
potential for discussion helpfulness if we don't have a common
understanding of classifications or implications (which we shouldn't have
because that's policy).  And I would be especially concerned if draft
Security Considerations sections started making statements like "this
attack only affects home networks, which are a Green network and therefore
not a concern".

On Wed, Jul 22, 2020 at 9:17 AM Chris Box (BT) <[email-masked]>
wrote:

> Rather than a hard classification of network X should always be color Y,
> in this list I think Glenn clarified it should be like the Windows model,
> i.e. when the user first connects to a network, the user is prompted to
> decide which trust level (color) it should be. They do this based on their
> own understanding of the context.
>

---

From: "Chris Box (BT)" <[email-masked]>
Date: Wed, 22 Jul 2020 18:30:20 +0100

Eric,

> attack only affects home networks, which are a Green network and therefore
Thinking aloud, would it be useful for a draft to say "this automatic
mechanism SHOULD NOT be used in a network the user has classified as Red"?

Chris

---

From: Eric Orth <[email-masked]>
Date: Wed, 22 Jul 2020 13:56:29 -0400

> mechanism SHOULD NOT be used in a network the user has classified as Red"?

I think that would be a problematic statement because, for many mechanisms
where a draft might consider making such a statement, the software choosing
to use such a mechanism may not have any reasonable signal of whether or
not the user would classify the network as such.  Maybe statements around
"when the implementation expects its users would classify the network as
Red", but that might be too loose to be helpful in such security
discussions. Maybe could be helpful for more refined statements like "this
mechanism could be particularly vulnerable to attacks on networks the user
has classified as Red, so implementations SHOULD make appropriate
mitigations unless the user has signaled a higher level of trust", but when
going into that much detail, is the simplification of saying "Red" really
helpful or is the draft going to need to clearly define the situational
dangers anyway?

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 22 Jul 2020 20:26:56 +0000

From: Eric Orth

On Wed, Jul 22, 2020 at 1:30 PM Chris Box (BT) <[email-masked]<mailto:[email-masked]>> wrote:

Eric,

And I'm curious about the intent for how this will be used.  How is this expected to be helpful in discussions or drafts? Seems we lose a lot of the potential for discussion helpfulness if we don't have a common understanding of classifications or implications (which we shouldn't have because that's policy).  And I would be especially concerned if draft Security Considerations sections started making statements like "this attack only affects home networks, which are a Green network and therefore not a concern".

Thinking aloud, would it be useful for a draft to say "this automatic mechanism SHOULD NOT be used in a network the user has classified as Red"?

I think that would be a problematic statement because, for many mechanisms where a draft might consider making such a statement, the software choosing to use such a mechanism may not have any reasonable signal of whether or not the user would classify the network as such.  Maybe statements around "when the implementation expects its users would classify the network as Red", but that might be too loose to be helpful in such security discussions. Maybe could be helpful for more refined statements like "this mechanism could be particularly vulnerable to attacks on networks the user has classified as Red, so implementations SHOULD make appropriate mitigations unless the user has signaled a higher level of trust", but when going into that much detail, is the simplification of saying "Red" really helpful or is the draft going to need to clearly define the situational dangers anyway?

<bhs>
I think these classifications are too complex and add an unnecessary level of abstraction that will cause users to draw false conclusions.

It’s a bit fuzzy as to what it means for a user to trust a network, in the context of discovering DoH servers. The draft mentions some aspects, but those aspects are all over the place, and I’m not sure they’re the right set.
For example the draft mentions whether the user trusts that the network is (1) operated with security, (2) operated with operational integrity (I’m not sure what this means), or (3) not compromised by attackers or malware.
The Windows model was mentioned in this thread – but Windows doesn’t ask users whether or not they trust the network; Windows asks whether the network is public (can anyone join = are all the devices attached to the network known to the user and not suspected of being malignant) or private. Whether or not you trust the other devices on the network is different from trusting whether the network is operated with security, integrity, or has been compromised.

Based on the discussion I’ve seen, it seems like what we want to know is whether the user wants to use DNS/DoH servers advertised by the local network, or not. And there may be some networks (network admins) that would want to say “If you don’t use my DNS/DoH servers, then I’m going to treat you like malware and do everything in my power to prevent you from using my network.” For example, a parent might want to have this sort of setting for their home network. And a corporate network would want this. If a coffee shop says this, the user can decide whether or not to use the network. I mean, the network belongs to the coffee shop and not the user, so the coffee shop should have the right to dictate usage policy. Users are completely free not to use the coffee shop network if they don’t like the shop’s network policies.

A classification for war zones and hostile regimes and blackhat networks strikes me as bizarre.

TL;DR: I think the network needs to be able to indicate whether network policy allows use of DNS/DoH servers other than those it advertises, and users (who have been informed of the network policy) can decide whether or not they want to use the locally advertised DoH servers (i.e., there are just 2 types of networks – (1) use advertised DNS/DoH and (2) don’t use advertised DNS/DoH). What the network does to detect and handle violations of its policy is out of scope. The network just needs to be able to express its policy. Depending on the device/application, the user may be able to go against the network policy, but they do so knowingly. OTOH, some devices/applications (e.g., enterprise-managed devices, parentally-controlled devices) may not allow users to go against the network policy. The system could even be defaulted not to use locally advertised DNS on new/unknown networks unless that violates expressed network policy (in which case the user is informed and asked if they want to use locally advertised per policy).  - Barbara
</bhs>

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 22 Jul 2020 16:54:34 -0400

On Wed, Jul 22, 2020 at 4:27 PM STARK, BARBARA H <[email-masked]> wrote:

>
> TL;DR: I think the network needs to be able to indicate whether network
> policy allows use of DNS/DoH servers other than those it advertises, and
> users (who have been informed of the network policy) can decide whether or
> not they want to use the locally advertised DoH servers (i.e., there are
> just 2 types of networks – (1) use advertised DNS/DoH and (2) don’t use
> advertised DNS/DoH). What the network does to detect and handle
> violations of its policy is out of scope. The network just needs to be able
> to express its policy.
>

Network operators can certainly have terms of service and usage policies.
I would not support making a special mechanism just for the policy related
to DNS server selection, to be presented to the user in isolation from any
other branding, advice, demands, and legalese.  In other words, this
problem is not specific to DNS, so ADD is not the place for it.
Personally, I would put it in CAPPORT, because network operator terms of
service are most naturally presented via a captive portal.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 22 Jul 2020 21:09:49 +0000

On Wednesday, 22 July 2020 20:54:34 UTC Ben Schwartz wrote:
> > violations of its policy is out of scope. The network just needs to be
> > able to express its policy.

i mostly resonate to this, except i'd like to see reliable signalling not just 
of policy but of violations. when something isn't working and the reason is 
network policy, i'd like to be able to tell the chromecast or the web browser 
or the IoT light bulb that what they're trying to do is expressly forbidden, 
rather than produce silent and ambiguous "doesn't work dunno why" conditions.

> other branding, advice, demands, and legalese.

DNS is part of bootstrapping. i may have to make a DNS request to validate a 
TLS certificate for example. if that's not going to work i'd like to be sure i 
know that it's not an accident, misconfiguration, or outage, but rather 
intent.

> In other words, this

my privately-owned edge network has only family, employees, and privately 
owned equipment. yes, there are terms of service. no, there aren't customers. 
CAPPORT is meant for a broader, distinct audience, and as written above, i may 
need to know why my DNS isn't working before i can speak to a policy service.

-- 
Paul

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 22 Jul 2020 21:15:52 +0000

From: Ben Schwartz <[email-masked]>

On Wed, Jul 22, 2020 at 4:27 PM STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> wrote:
TL;DR: I think the network needs to be able to indicate whether network policy allows use of DNS/DoH servers other than those it advertises, and users (who have been informed of the network policy) can decide whether or not they want to use the locally advertised DoH servers (i.e., there are just 2 types of networks – (1) use advertised DNS/DoH and (2) don’t use advertised DNS/DoH). What the network does to detect and handle violations of its policy is out of scope. The network just needs to be able to express its policy.
Network operators can certainly have terms of service and usage policies.  I would not support making a special mechanism just for the policy related to DNS server selection, to be presented to the user in isolation from any other branding, advice, demands, and legalese.  In other words, this problem is not specific to DNS, so ADD is not the place for it.  Personally, I would put it in CAPPORT, because network operator terms of service are most naturally presented via a captive portal.

I want devices and applications inside my home network to know that I want them to use the DNS resolvers my home network advertises. I don’t want to have to configure a captive portal for my home network. That’s silly. And my home network’s DNS policy is absolutely specific to DNS. It’s also simple: My policy is either (1) I don’t care what resolvers the app or device uses, or (2) I expect apps and devices to use the resolvers my network advertises (and devices/apps that don’t are suspected to be compromised/malware and may be treated as such). These aren’t terms and conditions for someone to agree to. It’s binary information. How or whether an app or device or malware presents this information to a user is up to the app/device/malware. I expect all malware to completely ignore my wishes.   - Barbara

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Jul 2020 17:27:23 -0400

STARK, BARBARA H <[email-masked]> wrote:
    > I want devices and applications inside my home network to know that I
    > want them to use the DNS resolvers my home network advertises. I don’t
    > want to have to configure a captive portal for my home network. That’s
    > silly. And my home network’s DNS policy is absolutely specific to

I find that the CAPPORT API interface is rather interesting because it is an
API to the local network that devices can programmatically connect to.
There doesn't have to be a "captive portal" (web page with silly logo) to use
the CAPPORT API.
It can easily be built in to home routers, or IoT security devices.

The most useful thing that I've proposed (with reasonable reception from
CAPPORT) is that there be an API return that says "quarantine" to a device.
I think that this is pretty important.

As Paul and others have said: it important that devices are able to
understand that the network connectivity challenges they are experiencing are
intentional.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 24 Jul 2020 15:32:45 +0200

On Wed, Jul 22, 2020 at 06:30:20PM +0100,
 Chris Box (BT) <[email-masked]> wrote 
 a message of 58 lines which said:

> Thinking aloud, would it be useful for a draft to say "this
> automatic mechanism SHOULD NOT be used in a network the user has
> classified as Red"?

I like the wording. (After of course proper warnings about the fact
that assessing the security/trust/etc of a network is hard, and you
can be wrong.)

But the real problem is that this draft deviates from the idea that
you can never now what the network does and therefore end-to-end
security is important (RFC 3552).