Subject: Re: [Add] New Threats ID for ADD

From: "Deen, Glenn" <[email-masked]>
Date: Wed, 22 Jul 2020 14:27:43 +0000

Hi Mohit,

Thanks for the feedback, let me attempt to clarify the proposal below inline....

On 7/21/20, 11:41 PM, "Add on behalf of Mohit Sethi M" <[email-masked] on behalf of mohit.m.sethi=[email-masked]> wrote:

    In-line.

    On 7/21/20 12:52 PM, Stephane Bortzmeyer wrote:
    > 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.
    >>
    >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-deen-add-threats-00__;!!PIZeeW5wscynRQ!7qOKFt8Ymhpa1DZyXwtTmrFhr02zuxsl0JY5pY6VI1Dd_CZg5vwrW8AujAWGq-4l$
    > 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.

    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

The classification is not meant to be a classification that is hard and fixed, nor is it someone I'm proposing be turned into a labelling which is somehow stored or communicated as descriptive information of the network.  As I've said in other notes,  this is all from the user's perspective and where a particular network falls for one user may well be different for another, and that classification may change over time based on events or experience or operational behavior the user wants from the network.

It is meant to help focus ADD's discussion of various proposals and the threats they face.  However, recognizing and acknowledging that not all network environments are as trusted as others, and on the two extremes range from well trusted networks on to clearly hostile networks - as you point out above.

Clearly each threat/trust level - Green/Yellow/Red calls for different mitigations to maintain integrity from the user's perspective.  So when we're discussing discovery and resolver information delivery proposals in ADD it is important to be able to also discuss what threats and mitigations are appropriate in each.  So not a network labelling proposal but a discussion and thought focusing proposal.

-glenn

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 22 Jul 2020 19:05:17 +0000

Chris/Glenn:

I certainly don't want to be a show stopper for whatever the working 
group wants to work on. Please treat my comments as those of an 
interested observer on the sidelines.

I understand that users can pick the classification based on their 
perception of threat vs. security. However, not all users are equal. 
While I expect most people on this list to make excellent decisions, 
there is a large and diverse population out there which may label the 
same networks very differently (insert quintessential grandmother 
example here). I also wonder about situations where the user is not 
actively selecting networks. At least in the past, many smartphones were 
happy to opportunistically join any open wireless network that provided 
some sort of Internet connectivity.

Anyhow, don't treat these as objections and rather as issues that might 
be worth considering going forward.

--Mohit

---

From: "Deen, Glenn" <[email-masked]>
Date: Wed, 22 Jul 2020 19:49:45 +0000

Mohit,

Thanks for the viewpoint and taking the time to think through the draft's ideas.

While I 100% agree that not all users are equal, they all do have the power to make choices when they connect to a network.  The motivation behind trying to roughly categorize the different threat/trust environments was to help ADD focus its discussion of what is needed and what is proportionally appropriate.  While a user connecting to a network that would fall into the Red environment is an important use scenario for the group to the consider, it's also not something that the vast majority of Internet users will actually encounter, so  when considering what is proportionally appropriate I hope it can be helpful to recognize that the user connecting to a trusted green, or even a yellow sort-of-trusted network doesn't need the same mitigations that they would need when connecting a device to the Black-Hat network.     We might need a special case beyond red - classified oh-hell-no for the Black-hat network.

Where I think/hope we may end up in practice is that ADD would produce outputs that will work in the Green zone without much if any fuss and issue for those users,  will work in the Yellow zone with some additional mitigations, and finally for Red zones call up more sophisticated mitigations to proportionally meet the threats present. So essentially common one method for discovery etc, but with appropriate and proportional mitigations added when used in different environments.

The classification approach in the draft is just meant to foster productive thinking and help us focus on appropriate proportional mitigations for each threat/trust environment.

It's that final consideration - appropriate and proportional - that is important to get right: Too light and we expose the user, too tight and we build a wall to DoH adoption.

Regards
Glenn

On 7/22/20, 12:05 PM, "Mohit Sethi M" <[email-masked]> wrote:

    Chris/Glenn:

    --Mohit

---

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

On Wednesday, 22 July 2020 19:49:45 UTC Deen, Glenn wrote:
> ... 

i am not mohit, but i have comments.

> While I 100% agree that not all users are equal, they all do have the power
> to make choices when they connect to a network.  ...
> While a user connecting to a network that would fall into the
> Red environment is an important use scenario for the group to the consider,
> it's also not something that the vast majority of Internet users will
> actually encounter, ...
> I hope it can be helpful to recognize that the user connecting to a trusted
> green, or even a yellow sort-of-trusted network doesn't need the same
> mitigations that they would need when connecting a device to the Black-Hat
> network.     We might need a special case beyond red - classified
> oh-hell-no for the Black-hat network.

glenn, i am concerned about your use of the words "user" and "trust" here. 
most of today's DHCP clients are embedded or IoT, and that trend will likely 
accelerate. they don't have UI's for the most part, other than for initial 
setup in some cases (like a chromecast). if we expect a judgement to be made 
based on trust, we have to make an assumption about whose judgement that will 
be and what their standard of trust will be.

noting that my chromecast ignores my DNS settings as told to it in DHCP, and 
just always goes to 8.8.8.8, this question is not editorial or academic in 
nature. surveillance capitalists who produce embedded Internet connected 
devices are likely to have a trust rubrik very different from mine.

and in any case, users are vastly unlikely to be able to make an informed 
decision about what kind of network they are connecting to. so even if a 
browser insisted on obtaining consent _before_ switching to an external DoH 
service, that would be _uninformed_ consent.

> The classification approach in the draft is just meant to foster productive
> thinking and help us focus on appropriate proportional mitigations for each
> threat/trust environment.

my reason for supporting adoption of your draft is that it will drag in all of 
these questions. good engineering must acknowledge economics and even 
politics, and either expressly avoid or expressly serve those interests.
 
> It's that final consideration - appropriate and proportional - that is
> important to get right: Too light and we expose the user, too tight and we
> build a wall to DoH adoption.

where you say user, i would say "privately-owned edge network operator". we 
may be able to coalesce around some kind of middle term so that the interests 
of some real or corporate person can always be held as paramount, and our task 
is reduced to enumerating or designating those so-called persons.

-- 
Paul

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Jul 2020 21:10:07 +0000

On Jul 22, 2020, at 12:49 PM, Deen, Glenn <[email-masked]> wrote:
> 
> While I 100% agree that not all users are equal, they all do have the power to make choices when they connect to a network.

There is widespread disagreement on the latter point. Proposals for operational practices and/or protocols that rely on that point are doomed to interminable discussion.

--Paul Hoffman

---

From: Steffen Nurpmeso <[email-masked]>
Date: Thu, 23 Jul 2020 01:15:51 +0200

Paul Hoffman wrote in
<[email-masked]>:
 |On Jul 22, 2020, at 12:49 PM, Deen, Glenn <[email-masked]> wrote:
 |> 
 |> While I 100% agree that not all users are equal, they all do have \
 |> the power to make choices when they connect to a network.
 |
 |There is widespread disagreement on the latter point. Proposals for \

And especially if it involves such an immense technical
background, beyond traffic light systems for things like cola.

 |operational practices and/or protocols that rely on that point are \
 |doomed to interminable discussion.

I favour separation of well-tested modules (since ever), so
DNS+D/TLS, xy+D/TLS etc.  That is hard for a light bulb which is
used first five years after it has been bought, even if DHCP would
be DHCP+DTLS, shall Michael Richardson have blinked in this
direction.  It is either root server based, ca-certificate based
or company-specific verification, then.

Bluetooth-like pairing btw worked for my 2019 TV of a company from
the Netherlands only with verification on the computer side, i did
not see the ID on the TV.  (It also has serious software problems,
and the PDF handbook, copyright 2018, like i think the entire TV
series, which earned industry prices, mentions OpenSSL 1.0.1j,
glibc 2.12.2, Libcurl 7.30.0, and i have disabled internet access
for it.  I do not know.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)