Subject: [Model-t] Possible new IAB program on Internet trust model evolution

From: Jari Arkko <[email-masked]>
Date: Fri, 24 Jan 2020 13:49:53 +0200

The IAB are considering starting up a programme on Internet
trust model evolution as described in the link at the bottom of this
email.

We'd like to get feedback on that idea and the text. As you may
be aware, in 2019 a number of documents were published on
this topic and discussions held (on the mailing list, SAAG, side
meeting at IETF-106, workshops, etc). There’s also a virtual
meeting coming up on February 14th.

To be clear, any output from this program would be text offered 
to the IETF for consideration - it is not within the IAB's remit, nor 
that of an IAB program, to modify a BCP. Nonetheless, an IAB 
program offers a good venue for this work, as it perhaps allows 
for more focus on the evolving architecture aspect within this space.

The plan is for the new program to be entirely open for participation,
similar to how the current work has already been. That is, the mailing
list is open for all interested to join, meetings are open and listed
in the public agendas. The IAB will find a chair or chairs for the
group to stay organised.

There's no specific deadline for this, but the IAB will consider this
further in the next few weeks, so if you could take a few minutes 
to share your thoughts on this that'd be great.

https://github.com/intarchboard/model-t-charter/blob/master/model-t-charter-00.md <https://github.com/intarchboard/model-t-charter/blob/master/model-t-charter-00.md>
https://www.iab.org/mailman/listinfo/model-t <https://www.iab.org/mailman/listinfo/model-t>

Stephen & Jari

---

From: Joachim Fabini <[email-masked]>
Date: Fri, 24 Jan 2020 14:49:34 +0100

Jari, Stephen, all,

I support the IAB initiative. As a detailed reply to some aspects
mentioned in the draft charter: imo
- it's needed that these threat/trust model activities find a home. The
IAB taking the lead can help in covering a wide variety of perspectives
(including aspects that some may consider research).
- the potential impact of the threat model on future activities is too
high to handle it within a closed group and/or side-meetings. Being open
for public participation and becoming more visible (by listing the
sessions in the program) can help to include perspectives of all
affected parties.
- the major challenge (imho) is an appropriate scope of the new model
while keeping it simple, usable and relevant for most of us (as your
draft and the charter both mention). Various areas/stakeholders/systems
may have conflicting views and priorities at
architectural/structural/protocol/security/privacy levels.
- An unbiased discussion/review on (explicit and, in particular,
implicit) prerequisites that RFC3552 relies on and if/how they changed
within the last 17 years may be a good start (fitting topic 2 of the
expected outputs).

At a technical level the term "compromised" (*) may benefit from a
refined perspective and definition. It sounds simple, but thinking of
group communications (multicast, broadcast) it becomes a challenge.

thanks
Joachim

PS: (*): or "compromisable"? The safe (realistic) assumption is to
consider any system to be vulnerable.

On 24/01/2020 12:49, Jari Arkko wrote:
> https://github.com/intarchboard/model-t-charter/blob/master/model-t-charter-00.md
> https://www.iab.org/mailman/listinfo/model-t
> 
> Stephen & Jari
> 
> 

-- 
---------------------------------------
Dr. Joachim Fabini
Senior Scientist
Institute of Telecommunications
TU Wien
Gusshausstrasse 25/E389
A-1040 Vienna, Austria
Tel: +43 1 58801-38813
mailto: [email-masked]
---------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Jan 2020 08:46:46 +1300

Hi,

I'm confused. What we have in RFC3552 is very intentionally guidance for
RFC writers on what they need to cover in their RFCs. Its specific purpose
was to get rid of "Security considerations are not discussed in this memo." 
Its purpose was not primarily to define an abstraction like a "trust model"
or a "threat model" (the draft charter seems a bit vague about which of those
it means).

I really do not want to see the pragmatic purpose of RFC3552 lost in the
effort to define these abstractions. I don't think that is the intention,
but the text seems to imply that RFC3552 was mainly a description of a
generic threat model, which it wasn't.

I am not against an IAB effort to analyse how the threat and trust models
(plural) have evolved since the security workshop [RFC2316] that ultimately
led to RFC3552. That seems like a good idea. An update of "Guidelines for
Writing RFC Text on Security Considerations" also seems like a good idea.
But the draft charter text seems to conflate these two separate lines of
action.

Incidentally, while writing the above it occurred to me why the phrase
"IAB program" has always slightly disturbed me. Really the proposal is
a virtual IAB workshop (whereas RFC2316 came from three days in a room
together in Murray Hill, NJ). A good idea, but not a program.

Regards
   Brian

On 25-Jan-20 00:49, Jari Arkko wrote:
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Jan 2020 12:03:11 -0800

Brian's comments match my recollection. Specifically, we didn't think we
were *defining* a threat model as much as documenting a consensus model
that already existed. Incidentally, it's not clear to me what a "trust
model" is. This is not a term that appears in 3552 nor is it a real term of
art that I am familiar with.

Taking a step back, I remain unpersuaded that the 3552 threat model is
really out of data. The two main deficiencies I have heard floated are:

1. That it doesn't take into account traffic analysis and pervasive
monitoring.
2. That the assumption that endpoints are uncompromised is unrealistic.

I can see some merit in the first point, but this seems to really be more a
matter of emphasis: 3552 already specifies a Dolev-Yao style attacker,
which means that it can observe all communications. So really what has
happened is that we have a clearer picture of just how realistic that is
and what you can do with that kind of access. I can see some kind of
update, but again it's less about threat model than about modern examples.

As far as the second point goes, I think that when you are thinking about
comsec protocols it's still true that you can't do much if you don't trust
the endpoints. I think 3552 could be a bit better about recognizing that
there are malicious actors in the system, though obviously that's implicit
in the discussion of DoS. Anyway, this doesn't seem like much of an update
to the threat model.

What does feel dated in 3552 (at least to me) is the emphasis on a bunch of
very old school protocols and the more or less total elision of the Web. In
particular, if we're talking in terms of threat model, the idea that you
have a lot of different untrusted programs running on your machine (i.e.,
in the JS VM) and that you need to secure them from each other really is
new and could use some documenting. It's worth noting, however, that (a)
that's largely about implementation and (b) that that system strives to
achieve the kind of "each endpoint its own isolated unit" ideal that 3552
asumes.

-Ekr

On Fri, Jan 24, 2020 at 11:47 AM Brian E Carpenter <
[email-masked]> wrote:

> Model-t mailing list
> [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Jan 2020 20:22:03 +0000

Hiya,

On 24/01/2020 20:03, Eric Rescorla wrote:
> Incidentally, it's not clear to me what a "trust

Crap! Checking back to the initial text, that was my
fault - must've been some form of Freudian typo though
'cause I also don't know what a "trust model" might be.
Please read s/trust model/threat model/ everywhere
relevant, and apologies for the slip up.

I've modified [1] to fix at least that,
Sorry again,
S.

[1]

---

From: Eliot Lear <[email-masked]>
Date: Fri, 24 Jan 2020 21:25:37 +0100

Hi Eric,

I appreciate your specificity.  It really helps to focus the discussion.

I would say that the world is a more complex place than it was when 3552 was written.  That is not to say that the document is out of date, but rather that it is reasonable to explore what confidentiality means in various contexts and how that relates to integrity.

Also, I do think it’s worthy addressing a slightly different threat model: when the endpoint that you purchased may be a threat to you, and whether there is something to be done about that.  I gave an example on another list of an Internet toy that has an undisclosed microphone and camera that invade’s a child’s privacy.

We discussed another case in which there needs to be auditing of train signaling systems.  And there are very complex cases involving medical devices that are probably worthy of discussion.

Does any of this require an update to 3552?  I think that would be premature to say.  But they’re probably worthy of discussion.

Eliot

> On 24 Jan 2020, at 21:03, Eric Rescorla <[email-masked]> wrote:
> 
> Brian's comments match my recollection. Specifically, we didn't think we were *defining* a threat model as much as documenting a consensus model that already existed. Incidentally, it's not clear to me what a "trust model" is. This is not a term that appears in 3552 nor is it a real term of art that I am familiar with.
> 
> Taking a step back, I remain unpersuaded that the 3552 threat model is really out of data. The two main deficiencies I have heard floated are:
> 
> 1. That it doesn't take into account traffic analysis and pervasive monitoring.
> I can see some merit in the first point, but this seems to really be more a matter of emphasis: 3552 already specifies a Dolev-Yao style attacker, which means that it can observe all communications. So really what has happened is that we have a clearer picture of just how realistic that is and what you can do with that kind of access. I can see some kind of update, but again it's less about threat model than about modern examples.
> 
> As far as the second point goes, I think that when you are thinking about comsec protocols it's still true that you can't do much if you don't trust the endpoints. I think 3552 could be a bit better about recognizing that there are malicious actors in the system, though obviously that's implicit in the discussion of DoS. Anyway, this doesn't seem like much of an update to the threat model.
> 
> What does feel dated in 3552 (at least to me) is the emphasis on a bunch of very old school protocols and the more or less total elision of the Web. In particular, if we're talking in terms of threat model, the idea that you have a lot of different untrusted programs running on your machine (i.e., in the JS VM) and that you need to secure them from each other really is new and could use some documenting. It's worth noting, however, that (a) that's largely about implementation and (b) that that system strives to achieve the kind of "each endpoint its own isolated unit" ideal that 3552 asumes.
> 
> -Ekr
> 
> 
> On Fri, Jan 24, 2020 at 11:47 AM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> > https://github..com/intarchboard/model-t-charter/blob/master/model-t-charter-00.md <https://github.com/intarchboard/model-t-charter/blob/master/model-t-charter-00.md>
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/architecture-discuss <https://www.ietf.org/mailman/listinfo/architecture-discuss>
> >
> 
> --
> Model-t mailing list
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/architecture-discuss <https://www.ietf.org/mailman/listinfo/architecture-discuss>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 24 Jan 2020 12:35:54 -0800

On Fri, Jan 24, 2020 at 12:03 PM Eric Rescorla <[email-masked]> wrote:

> I can see some merit in the first point, but this seems to really be more
> a matter of emphasis: 3552 already specifies a Dolev-Yao style attacker,
> which means that it can observe all communications.
>
So really what has happened is that we have a clearer picture of just how
> realistic that is and what you can do with that kind of access. I can see
> some kind of update, but again it's less about threat model than about
> modern examples.
>

One of the changes I'm interested in seeing is a shift away from seeing
this in terms of a single communication channel, which I believe is
inherent in this text:

   By contrast, we assume that the attacker has nearly complete control
   of the communications channel over which the end-systems communicate.
   This means that the attacker can read any PDU (Protocol Data Unit) on
   the network and undetectably remove, change, or inject forged packets
   onto the wire.  This includes being able to generate packets that
   appear to be from a trusted machine.  Thus, even if the end-system
   with which you wish to communicate is itself secure, the Internet
   environment provides no assurance that packets which claim to be from
   that system in fact are.

One of the biggest shifts in the pervasive surveillance case is that the
attacker is both likely to be present on any alternative communication
channel and likely has sufficient context over time to cross-correlate
communications.  We're moving from an omnipotent attacker to one that is
also both omnipresent and eternal.  While that may have been obvious to
those specifying RFC 3552, it is hard to read in the current document for
those who were once more naïve.   That doesn't really mean RFC 3552 is
wrong, just that explaining the implications in the current context may be
useful.

> in the discussion of DoS. Anyway, this doesn't seem like much of an update
Here, I think the point is really to move the IETF away from thinking in
terms of host requirements. I agree with you that there are pieces to this
that are very similar whether you think of  JS code in a sandboxed tab or
about an IoT device or about TOPS-20 device connected to an IMP.  But if
you assume that the PC running the browser hosting that tab is the unit of
analysis, you might have a very bad time.  Again, not really a change in
the threat model, but a change in the context.  This may be a way of saying
that I agree with your point below.

regards,

Ted

> What does feel dated in 3552 (at least to me) is the emphasis on a bunch
> of very old school protocols and the more or less total elision of the Web.
> In particular, if we're talking in terms of threat model, the idea that you
>> https://github..com/intarchboard/model-t-charter/blob/master/model-t-charter-00.md
>> <https://github.com/intarchboard/model-t-charter/blob/master/model-t-charter-00.md>

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 24 Jan 2020 12:51:06 -0800

EKR said:

"What does feel dated in 3552 (at least to me) is the emphasis on a bunch
asumes."

[BA] I agree that RFC 3552 does feel dated with respect to today's Web.  In
a number of cases, it has become clear that the term "endpoint" is too
general, and that we may need to define much more precisely what endpoint
elements (e.g. JS applications, native browser code, trusted hardware
modules, etc.) are trusted with what data.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 24 Jan 2020 13:50:15 -0800

Hi Jari,
>to share your thoughts on this that'd be great.

The technical summary of RFC 3552 is as follows: "What does this 
protocol do and why does the community need it?"  The Abstract states 
that the document provides guidelines to RFC authors on how to write 
a good security consideration section.  In the draft charter, that 
document is interpreted as the Internet threat model for protocol 
design whereas the title in the draft charter is about the Internet 
threat model.  Is the proposed IAB program about (re)defining the 
Internet threat model [1]?

The draft charter mentions "information centralisation".  There isn't 
any direct link between that topic and what is in RFC 3552.  If the 
Internet is considered in terms of end-points, that topic would not 
fit in.  This topic also does not fit in if the discussion is 
intended to be about IETF protocols.

My preference would be to have the initial discussion of an RFC 3552 
update within the IETF instead of this venue.  This would avoid the 
awkwardness of having to offer text to the IETF.

Regards,
S. Moonesamy

1. The threat model for a few IETF protocols go beyond what is in 
Section 3 of RFC 3552.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 24 Jan 2020 17:56:02 -0800

On 1/24/2020 12:35 PM, Ted Hardie wrote:

>     As far as the second point goes, I think that when you are
>     thinking about comsec protocols it's still true that you can't do
>     much if you don't trust the endpoints. I think 3552 could be a bit
>     better about recognizing that there are malicious actors in the
>     system, though obviously that's implicit in the discussion of DoS.
>     Anyway, this doesn't seem like much of an update to the threat model.
>
>
> Here, I think the point is really to move the IETF away from thinking
> in terms of host requirements. I agree with you that there are pieces
> to this that are very similar whether you think of  JS code in a
> sandboxed tab or about an IoT device or about TOPS-20 device connected
> to an IMP.  But if you assume that the PC running the browser hosting
> that tab is the unit of analysis, you might have a very bad time. 
> Again, not really a change in the threat model, but a change in the
> context.  This may be a way of saying that I agree with your point below.

Phrasing that as "don't trust the endpoints" is probably inappropriate.
My personal worry is the cascading impact of end-point compromise. Take
the example of a large network. Large network means multiple routers. If
the multiple is high enough, we have strong risks that one of those will
be compromised at some point. If we merely "trust the endpoints", then a
single compromise of one of the endpoints means the game is over. But it
does not have to be so. In an ideal world, implementations of the
routing protocol should be able to detect aberrant behavior and isolate
the compromised node. In practice, that's really hard. But there are
still general principles like "least amount of privilege" or "need to
know basis" that could help. I would really like that protocol designers
think about that too, instead of merely asserting trust in the endpoints.

And I would really like to get rid of the assumption about isolated
networks being secure...

-- Christian Huitema

---

From: Eliot Lear <[email-masked]>
Date: Sat, 25 Jan 2020 18:58:04 +0100

> On 25 Jan 2020, at 02:56, Christian Huitema <[email-masked]> wrote:
> 
> 

Why?  They are the source of just about all compromise attacks.
> My personal worry is the cascading impact of end-point compromise. Take the example of a large network. Large network means multiple routers. If the multiple is high enough, we have strong risks that one of those will be compromised at some point. If we merely "trust the endpoints", then a single compromise of one of the endpoints means the game is over. But it does not have to be so. In an ideal world, implementations of the routing protocol should be able to detect aberrant behavior and isolate the compromised node. In practice, that's really hard.
> 
We sell product that does this today.  But it is hard, which is why people pay us.  Of course, it gets harder with encryption, but we even have product for that.  I prefer the other approach: tell us what good behavior looks like (manufacturer usage descriptions).

> But there are still general principles like "least amount of privilege" or "need to know basis" that could help.
> 
Indeed.
> I would really like that protocol designers think about that too, instead of merely asserting trust in the endpoints.
> 

How much is this the protocol and how much is the application?  The protocols most apps are using today are, ermmm, HTTP.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 25 Jan 2020 23:36:39 -0800

It's probably useful to put the text in 3552 in context, which was
primarily about designing COMSEC protocols. Our ability to build two party
protocols which survive one of the parties being compromised is fairly
limited. We *do* have some praxis for building N party protocols which
gracefully degrade when some of the nodes are compromised (for instance
consensus protocols). Of course, the exact properties of those protocols
can be difficult to succinctly state.

I'm not quite sure I understand what you mean when you say "They are the
source of just about all compromise attacks." I'm not saying it's not true,
but perhaps you could elaborate.

-Ekr

On Sat, Jan 25, 2020 at 9:58 AM Eliot Lear <[email-masked]> wrote:

> the multiple is high enough, we have strong risks that one of those will be
> compromised at some point. If we merely "trust the endpoints", then a
> does not have to be so. In an ideal world, implementations of the routing
> protocol should be able to detect aberrant behavior and isolate the
> compromised node. In practice, that's really hard.
>
> We sell product that does this today.  But it is hard, which is why people
> pay us.  Of course, it gets harder with encryption, but we even have
> product for that.  I prefer the other approach: tell us what good behavior
> looks like (manufacturer usage descriptions).
>
> I would really like that protocol designers think about that too, instead
> of merely asserting trust in the endpoints.
>
>
> How much is this the protocol and how much is the application?  The
> protocols most apps are using today are, ermmm, HTTP.
>
> Eliot
>

---

From: Eliot Lear <[email-masked]>
Date: Sun, 26 Jan 2020 10:44:05 +0100

Hi Eric,

I apologize for the length of this missive.  I’ve included examples that are either from real life or plausible to the point of inevitability.

> On 26 Jan 2020, at 08:36, Eric Rescorla <[email-masked]> wrote:
> 
> It's probably useful to put the text in 3552 in context, which was primarily about designing COMSEC protocols. Our ability to build two party protocols which survive one of the parties being compromised is fairly limited.

Indeed.

> We *do* have some praxis for building N party protocols which gracefully degrade when some of the nodes are compromised (for instance consensus protocols). Of course, the exact properties of those protocols can be difficult to succinctly state.

They are, and they are hard to build, and they have their own failure modes.(*). But I really wasn’t going there, at least not directly.  Let’s look at three specific examples that I’ve mentioned:

1.  Train signaling system needs to be audited both live and retrospectively in the case of accidents.  This has to happen in such a way that the auditor sees precisely what was sent by one endpoint and received by the other.

2.  The case of “parent doesn’t want Internet toy to send video of child”, when the camera is undisclosed (it’s an analog to the privacy analysis on Alexa[1] and the now infamous NEST episode[2]).

3. CPAP machine or an AED/pace maker provide a control interface to the doctor but the patient or his next of kin wants the data.

Each example has a slightly different threat model, in addition to what you stated in 3552. In the first case, we add mistakes on the part of the operator (certainly the most common at this point**), and endpoint compromises.  In the second case, it is the manufacturer themselves that is the threat, for failing to have disclosed what they are doing.

The third case is more difficult.  Let’s say a patient died.  Did the patient die (a) of natural causes, (b) due to a mistake made by the patient or a care giver at home, (c) due to a mistake made by the healthcare professional on the other end, or (d) due to an cyberattack?  It may be impossible for the next of kin to know if there is no network audit capability.  Yes, this is a messy case, which makes it a good one to explore.

The program can explore COMSEC, UX, and higher level issues as well, like economics.  That latter one is actually important because if in the end the use cases above are going to get trumped by economics on the part of manufacturers, what’s the point of specifying mechanism?   This also goes to another point about which the IAB has had concern: concentration and control points.  That can be explored as well here. This does look to relax the assumption you laid down in 3552 about endpoints, but I don’t think it dramatically changes things.

Also, when you wrote 3552, there was really only the theoretical notion of a cyberwar, ruling out attacks with infinite or near infinite resources.  That’s now an every day reality.  In RFC 7958, we sort of ruled them back in, but I think it’s worth exploring a bit more what that means.  A program for that is a very good idea.

> 
> I'm not quite sure I understand what you mean when you say "They are the source of just about all compromise attacks." I'm not saying it's not true, but perhaps you could elaborate.
> 

With apologies, I was shamelessly stating the obvious: the vast source of bugs are on end devices, not because middle boxes are better designed (some are, some aren’t), but because of sheer numbers.  Well, if endpoints are where the problems are, that’s where we need to spend time as a community.

Eliot

(*) My favorite example of a consensus protocol that had “good intentions" was BSD timed.  “It was a dark and stormy night”, when every participant had an unstable ticker in a different way, leading to time storms.
(**) For a very interesting read for anyone interested in IoT, I highly recommend “Famous British Railway Disasters, Ian Allan Pub, 2000.  https://www.amazon.com/British-Railway-Disasters/dp/0711024707
[1] Malkin, et. al., “Privacy Attitudes Toward Smark Speaker Users”, Proceedings of Privacy Enhancing Technologies,  2019.
[2] https://arstechnica.com/gadgets/2019/02/googles-nest-security-system-shipped-with-a-secret-microphone/

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Sun, 26 Jan 2020 20:05:51 +0700

Dear architecture-discuss,

Networks of Interests: Trusts and Distrusts...?

In trying to follow the fluxes of the discussion, I begin with such basic
understandings below:

Networks of Interests: Trust and Distrust...

- when the interests are understood by either/all parties involved there
are (networks of) trusts.

- when the interests are not understood/accepted by either/all parties
involved there are (networks of) suspicions/threats/distrusts.

For the Internet:

As it is about networks of computers, of communications, so it is about
identifying  critical points of security: those threats and trusts --actual
and potential (1)

Two levels/layers to consider of analyzing the securities of the networks
of communications: technical architecture --which is about design
environment, (about "arstechnica"?)-- and the architecture's deployment
environments...

RFC 2316 and 3552 is considered as they are references of information and
best current practice of the Internet engineering (2).

The ITU of the UN report "Leveraging Tech..." and the Internet Society
Report "Consolidation in the Internet Economy" as kinds of analytical tools
to mapping a context (of problems, thus about real social conditions). (3)

(1) The identifications depends on interpretations and evaluations
(approaches and perspectives).

(2) https://www.rfc-editor.org/info/rfc2316;
https://www.rfc-editor.org/info/rfc3552

(3) The ITU of the UN report “Fast-forward Progress: Leveraging tech to
achieve the global goals”
https://www.itu.int/en/sustainable-world/Documents/Fast-forward_progress_report_414709%20FINAL.pdf

2019 ISOC Global Internet Report "Consolidation in the Internet Economy"
https://future.internetsociety.org/2019/wp-content/uploads/sites/2/2019/04/InternetSociety-GlobalInternetReport-ConsolidationintheInternetEconomy.pdf

Regard,
Guntur Wiseno Putra

Pada Minggu, 26 Januari 2020, Eliot Lear <[email-masked]> menulis:

> Hi Eric,
>
> I apologize for the length of this missive.  I’ve included examples that
> are either from real life or plausible to the point of inevitability.
>
> limited.
> We *do* have some praxis for building N party protocols which gracefully
> degrade when some of the nodes are compromised (for instance consensus
> protocols). Of course, the exact properties of those protocols can be
> difficult to succinctly state.
>
>
> They are, and they are hard to build, and they have their own failure
> modes.(*). But I really wasn’t going there, at least not directly.  Let’s
> look at three specific examples that I’ve mentioned:
>
> 1.  Train signaling system needs to be audited both live and
> retrospectively in the case of accidents.  This has to happen in such a way
> that the auditor sees precisely what was sent by one endpoint and received
> by the other.
>
> 2.  The case of “parent doesn’t want Internet toy to send video of child”,
> when the camera is undisclosed (it’s an analog to the privacy analysis on
> Alexa[1] and the now infamous NEST episode[2]).
>
> 3. CPAP machine or an AED/pace maker provide a control interface to the
> doctor but the patient or his next of kin wants the data.
>
> Each example has a slightly different threat model, in addition to what
> you stated in 3552. In the first case, we add mistakes on the part of the
> operator (certainly the most common at this point**), and endpoint
> compromises.  In the second case, it is the manufacturer themselves that is
> the threat, for failing to have disclosed what they are doing.
>
> The third case is more difficult.  Let’s say a patient died.  Did the
> patient die (a) of natural causes, (b) due to a mistake made by the patient
> or a care giver at home, (c) due to a mistake made by the healthcare
> professional on the other end, or (d) due to an cyberattack?  It may be
> impossible for the next of kin to know if there is no network audit
> capability.  Yes, this is a messy case, which makes it a good one to
> explore.
>
> The program can explore COMSEC, UX, and higher level issues as well, like
> economics.  That latter one is actually important because if in the end the
> use cases above are going to get trumped by economics on the part of
> manufacturers, what’s the point of specifying mechanism?   This also goes
> to another point about which the IAB has had concern: concentration and
> control points.  That can be explored as well here. This does look to relax
> the assumption you laid down in 3552 about endpoints, but I don’t think it
> dramatically changes things.
>
> Also, when you wrote 3552, there was really only the theoretical notion of
> a cyberwar, ruling out attacks with infinite or near infinite resources.
> That’s now an every day reality.  In RFC 7958, we sort of ruled them back
> in, but I think it’s worth exploring a bit more what that means.  A program
> for that is a *very* good idea.
>
>
> With apologies, I was shamelessly stating the obvious: the vast source of
> bugs are on end devices, not because middle boxes are better designed (some
> are, some aren’t), but because of sheer numbers.  Well, if endpoints are
> where the problems are, that’s where we need to spend time as a community.
>
> Eliot
>
> (*) My favorite example of a consensus protocol that had “good intentions"
> was BSD timed.  “It was a dark and stormy night”, when every participant
> had an unstable ticker in a different way, leading to time storms.
> (**) For a very interesting read for anyone interested in IoT, I highly
> recommend “Famous British Railway Disasters, Ian Allan Pub, 2000.
> https://www.amazon.com/British-Railway-Disasters/dp/0711024707
> [1] Malkin, et. al., “Privacy Attitudes Toward Smark Speaker Users”,
> Proceedings of Privacy Enhancing Technologies,  2019.
> [2] https://arstechnica.com/gadgets/2019/02/googles-nest-
> security-system-shipped-with-a-secret-microphone/
>

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 27 Jan 2020 10:54:27 +0100 (CET)

Il 26/01/2020 10:44 Eliot Lear <[email-masked]> ha scritto:

Part of the issue is, when you have to write "security considerations", what do you mean by "security". If that means "security of the protocol", I can see why you end up with a theoretical approach that defines the security of the endpoints as out of scope. However, if that means "security of the applications that will be built over the protocol", or "security of the users of the protocol", and if security includes privacy and data protection (or even human rights, as the people in HRPC would argue), then the scope becomes much broader. Given the desired focus on prioritizing end-user needs, the meaning should be the latter.

In that case, in the almost 20 years that have passed since RFC 3552, the scenario has changed significantly. For example, 20 years ago end-users were, at least in theory, fully in control of what ran on their endpoints, which basically consisted of personal computers; nowadays, most end-users access the Internet via smartphones, where their control is much more limited - and let alone IoT devices; both smartphones and IoT devices are categories of endpoints that did not exist at the time. 20 years ago there was no "cloud" or "edge computing", and even if the cloud is just someone else's computer, still the location of personal information over the network has significantly changed. 20 years ago the Internet was the Internet, i.e. a permissionless innovation network of networks where lots of people produced content and services even on a very small scale; nowadays, apart from email and the web, many of the most popular services consist of walled gardens, and even network infrastructure is remarkably centralised, not in topological terms but in terms of ownership and control.

I think that it would be good to discuss how these things impact the security of the user, and how they should be considered when writing new protocols. Perhaps, after the discussion, we could conclude that they do not affect protocol design. But I think that in some cases they could, and so the discussion would be useful.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Eliot Lear <[email-masked]>
Date: Tue, 28 Jan 2020 12:33:42 +0100

[Last message of the day for me, promise.  Thanks for your patience.]

Hi Stephen,

I know I’ve said this in the past, but I hope we’re actually agreeing more than disagreeing here.  See below.

> On 28 Jan 2020, at 11:02, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
> On 28/01/2020 06:44, Eliot Lear wrote:
>> From an IAB program standpoint, the real question here is this: what
>> are the architectural building blocks that are required?
> I'm not sure I agree. ISTM you envisage a programme that
> tries to establish that existing IETF consensus as to the
> use of e2e encryption needs to be changed, which I don't
> think is a goal here. Personally, I think of this as a
> place to work on whether or not it's possible to extend
> (not replace) the 3552 threat model to cater for changes
> since 3552 was written. (I do think that's an interesting
> question and it's unclear to me if the answer is "yes" or
> "would like to, but it's not usefully feasible.")

3552 a great document! It provides great guidance for a very common usage pattern. As such, we should tread very carefully, but tread we must, no?  I do not suggest we replace it, but rather examine assumptions and its applicability.  Christian’s comment is apt: do we assume that devices are safe because they are disconnected?

> 
> Now, it's of course valid to point out that comsec (as
> ekr may put it) if applied e2e doesn't by itself meet
> all requirements stated in your examples, to which I'd
> maybe argue to extend the Internet threat model with
> some statement along the lines of: "if an endpoint
> does need to see traffic content or significant meta-
> data, then you need to design your protocol so that that
> endpoint is an endpoint at which relevant cryptographic
> mechanisms are validly terminated, according to the
> expectations of the cryptographic protocol(s) in use (e.g.
> TLS, IPsec).

I really don’t know what expectations a protocol has, but if part of an existing code base / specification can reasonably satisfy clear and well justified requirements, I would rather beg, borrow, and steal than rewrite, so as to capitalize on past experience.  That’s not to say we should change any existing protocol, but rather depend on the parts we can leverage.

> So I don't think, for the purposes of this exercise,
> we're considering existing widely deployed protocols as
> malleable building blocks, whether that protocol is
> TLS or some (deployed) train signalling system.

Building blocks must be stable and not malleable so that others can depend on their behavior.  I hope we don’t look at any single example to design those blocks, which is why I raised several; I hope others would raise others, as Watson did; and I would suggest that this program take a walk before run approach.

In summary (otherwise known as burying the lede), my suggestion is to test / validate these sorts of examples, maybe decompose as required a bit of what we have “on the truck” into various components that could prove useful, pick from the best, create the rest, and then demonstrate value.(*)

Eliot

(*) There is probably a separate more general question hiding here as to how we build protocols, and what is the right granularity for their constituent parts.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 28 Jan 2020 09:35:44 -0500

On Tue, Jan 28, 2020 at 1:44 AM Eliot Lear <lear=[email-masked]>
wrote:

> Hi Watson,
>
> On 28 Jan 2020, at 02:35, Watson Ladd <[email-masked]> wrote:
>
>
>
> On Sun, Jan 26, 2020 at 1:44 AM Eliot Lear <[email-masked]> wrote:
>
>>   Let’s look at three specific examples that I’ve mentioned:
>>
>> 2.  The case of “parent doesn’t want Internet toy to send video of
>> child”, when the camera is undisclosed (it’s an analog to the privacy
>> analysis on Alexa[1] and the now infamous NEST episode[2]).
>>
> I've got a few more examples from real life:
>
> 4: We need to see who is sending pictures of Winnie the Pooh.
>
> 5: We don't want pictures of the inside of our detention centers to appear
> online.
>
> 6: I want to see everyone's credit card number at the coffee shop I run.
>
> Any discussion of tapping network communications because endpoints can't
> be trusted needs to take these cases seriously.
>
>
>
> Absolutely.  What I am suggesting is a relatively new twist on an old
> problem(*).  It’s important to understand the economic and policy aspects
> of how/whether to avoid [4] and [5], how to avoid [6] while at the same
> time addressing use cases I mentioned.
>
> So… today’s new information comes courtesy of the EFF.
>
>
> https://www.eff.org/deeplinks/2020/01/ring-doorbell-app-packed-third-party-trackers
>
> Here we have yet another IoT device that, from at least one person’s
> perspective is invading home privacy.  And again, it is the device itself
> that is the threat.  In this case, it’s probably a more manageable threat,
> because one can simply not get a NEST.  Try not getting a CPAP machine.
>
> And this brings us around to what layer to solve the problem at.  Some of
> this may need to be dealt with at layer 9 rather than at lower layers.  We
> should have that discussion too.
>
>
>
> Increasingly corporate networks are moving away from network layer access
> controls and using user authentication over TLS, so-called BeyondCorp
> model, including checking endpoint posture through management.
>
>
> The endpoint being the focus for attacks is very important.  As we shore
the endpoint up further, attacks may reduce in number, but will likely
increase in severity due to state sponsored actors.  Work in RATS, TEEP,
SUIT, and MUD should be considered in terms of how assurance of systems is
provided and also looking at the use cases to ensure there are sometimes
when you don't want that level of attestation.  User ownership of data is
another area.  These build on zero-trust/BeyondCorp/data-centric models and
are examples of active work in the IETF on the end point.  They also have
the potential to shift management and architectural models within the
enterprise.

Best regards,
Kathleen

> I don’t think this solves the railroad case.  Do you?  Just to clarify the
> example:
>
> According to their logs, two separate signals received  “set your lights
> to green” at the same time, causing two trains to crash into each other.
> According to the signal controller’s logs, it sent “set your lights to
> green” to only one signal.  What happened?
>
> All of the cases we are discussing have slightly different flavors of
> threats.  From an IAB program standpoint, the real question here is this:
> what are the architectural building blocks that are required?  Keep in
> mind, some of those blocks could be code and some could be policy.
>
> One goal should be code reuse. It is probably best that the people
> building the train signal *not* reinvent everything, but rather benefit
> as much as they can from the experience and results that you, EKR, and a
> great many other people have brought to society.
>
> Eliot
>
> (*) It’s also important to not fall into old tribal communication
> patterns, while recognizing the realities of the concerns raised by you,
> Watson, and me.
>

-- 

Best regards,
Kathleen

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 28 Jan 2020 10:16:09 -0500

I am a bit concerned by the emphasis on what appear to be application 
policy, business policy, or government policy.  To the degree that these 
are decoupled from the technology we define, my impression is that the 
IETF is neither skilled at nor influential with regard to these topics. 
We can spend a lot of time and energy on them.  They are interesting 
topics.  But are they really our business?

Yours,
Joel

On 1/28/2020 1:44 AM, Eliot Lear wrote:
> Hi Watson,
> 
>> On 28 Jan 2020, at 02:35, Watson Ladd <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>>
>> On Sun, Jan 26, 2020 at 1:44 AM Eliot Lear <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     retrospectively in the case of accidents.  This has to happen in
>>     such a way that the auditor sees precisely what was sent by one
>>     endpoint and received by the other.
>>
>>     child”, when the camera is undisclosed (it’s an analog to the
>>     privacy analysis on Alexa[1] and the now infamous NEST episode[2]).
>>
>>     3. CPAP machine or an AED/pace maker provide a control interface
>>     to the doctor but the patient or his next of kin wants the data.
>>
>>
>> 5: We don't want pictures of the inside of our detention centers to 
>> appear online.
>>
>> Any discussion of tapping network communications because endpoints 
>> can't be trusted needs to take these cases seriously. 
> 
> 
> problem(*).  It’s important to understand the economic and policy 
> aspects of how/whether to avoid [4] and [5], how to avoid [6] while at 
> the same time addressing use cases I mentioned.
> 
> perspective is invading home privacy.  And again, it is the device 
> itself that is the threat.  In this case, it’s probably a more 
> manageable threat, because one can simply not get a NEST.  Try not 
> getting a CPAP machine.
> 
> And this brings us around to what layer to solve the problem at.  Some 
> of this may need to be dealt with at layer 9 rather than at lower 
> layers.  We should have that discussion too.
> 
> 
>>
>> Increasingly corporate networks are moving away from network layer 
>> access controls and using user authentication over TLS, so-called 
>> BeyondCorp model, including checking endpoint posture through management.
> 
> I don’t think this solves the railroad case.  Do you?  Just to clarify 
> the example:
> 
> threats.  From an IAB program standpoint, the real question here is 
> this: what are the architectural building blocks that are required? 
>   Keep in mind, some of those blocks could be code and some could be policy.
>

---

From: John C Klensin <[email-masked]>
Date: Tue, 28 Jan 2020 11:20:45 -0500

--On Tuesday, January 28, 2020 10:16 -0500 "Joel M. Halpern"
<[email-masked]> wrote:

> I am a bit concerned by the emphasis on what appear to be
> application policy, business policy, or government policy.  To
> the degree that these are decoupled from the technology we
> define, my impression is that the IETF is neither skilled at
> nor influential with regard to these topics. We can spend a
> lot of time and energy on them.  They are interesting topics.
> But are they really our business?

Joel,

I've been trying, not very successfully, to follow this very
lively discussion, but two observations which I hope are not out
of context:

(1) I think that "neither skilled nor influential ... [and
therefore] not our business" leads us down a path whose
destination is irrelevancy.  Even for link encryption (and
perhaps more so when the scope is broadened), we should probably
recognize that mounting pressures from law enforcement (both
associated with governments some of us like if they like any
governments at all and those they don't like or who are viewed
with more suspicion) could easily lead to regulations for
government access to keys or other backdoors or even to outright
bans on public use of cryptography.  Even noting that arguments
from the technical community had major influence on killing the
Clipper Chip effort and that making those arguments was very far
from "not our business", it seems to me that good engineering
requires that we not put our heads in the sand and pretend that
the world is different then it actually is or might be becoming
when we design protocols.   In particular, that may mean that,
in some places, we should be writing specifications less in
terms of "if you want to have privacy, you MUST do X" and more
in terms of "...SHOULD do X unless that is not feasible but, if
it isn't, then the fallback approach SHOULD include Y and Z".
In the real world, "feasible" may include political of other
constraints, not just constraints imposed by physics.  We may
not always be able to figure out good alternatives to our
preferred recommendations, but I suggest that making a balanced
and good faith effort to understand the problems and the
environments in which we expect our protocols will be used will
lead to better design even when we don't have good solutions.  

Or, to put it more negatively, if we fail to understand and try
to account for those environments, we risk being put in a
position in which _we_ are the ones responsible for Internet
fragmentation and/or for protocol work moving to bodies other
than the IETF because regulators make conforming implementations
of IETF protocols illegal or commercial firms discover that
conforming implementations cannot be developed and sold.

(2) If I correctly understand the issues that Eliot, Watson, and
Kathleen are exploring, the key involves the rather classic
security issues of authorization and authentication --who should
have access to particular information and how do we tell they
are who they claim to be?  In a way, maintaining and enforcing a
non-trivial list of authorized parties but keeping everyone and
everything else out (the example of some doctors and the
patients themselves is very helpful for thinking about this) is
a lot harder than keeping everyone out except those who control
the endpoints (whatever that means).   But most of that problem
is technical and, if we don't have the expertise (I'm tempted to
say "any more") that is a problem for us.

In both cases, it seems to me that an IAB Program (or at least
one or more serious workshops) are exactly the right model for
addressing these problems for at least two reasons:  The IAB is
in a much better position than, say, an IETF WG, to recruit
specific expertise to cover perspectives and areas of expertise
that are not widely available in the IETF.  It is also perfectly
reasonable for such a program to produce recommendations about
issues that need to be considered even if they have no good
solutions or even if they are convinced that there are no
solutions out there.  I can only hope that the IAB will hold
itself to a very high standard of including multiple
perspectives (even perspectives with which IAB members and their
perception of IETF consensus are in significant disagreement)
and a broad range of expertise in the Program and that the
community will hold the IAB accountable if they do not.  If the
way the IAB were to recruit Program members involved asking for
volunteers from within the IETF community and then further
narrowing the Program's perspective by selecting people from
among those volunteers who agreed with the IAB's own views, the
Program would likely be a waste of time or worse.

    john

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 28 Jan 2020 11:50:02 -0500

> say "any more") that is a problem for us.

A number with expertise in this area are engaged in the SACM, RATS, TEEP,
and SUIT working groups.  More were starting to come for SMART, but that
was shutdown.  Personally, I think engaging those who have expertise in
this area is important and some draft authors who came for SMART should be
engaged.  They are on the front lines of malware and other system level
attacks.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Jan 2020 07:46:28 +1300

> topics.  But are they really our business?

Joel, I think they are part of the threat model (exactly as we have argued
in RFC1984, RFC2804 and RFC7258). In that sense they are absolutely our business.
Just in the last few days, key escrow has been back in the news, for example.

Ultimately, technology influences policy, so our choices are not without
impact.

Regards
    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 28 Jan 2020 20:23:05 +0100

Stephen,

I totally do not get how you read Eliots text as being about TLS.

I read Eliot/Watsons mails to be in the same direction as what i was
pointing out yesterday.

Let me try to abstract maybe better:

In the past, we have primarily looked at the security implications
of individual protocols, communicating mostly between two endpoints
and attacks against this communication by observers, MitM, or
malicious endpoints.

Of course, we went beyond that but not systematically to the point that
instead of concentrating only on the communication channels, we would
instead concentrate also on the properties of modules whose complete
external behavior is defined through a set of interfaces. And then
define security properties observing that superset of interfaces.

Once you have this model, Watson/Eliots examples are easy translated
into propagation properties between these interfaes.

My yesterdays mail points was more about the problem of having
modules that are small enough or implemented in a way that at
least specific properties can be verified instead of just having to
trust the module vendor. Or having interfaces that allows another
module to verify/control behavior. 

Of course, the fun difference with this model is that in the most
simple of cases, you could try to view a complete router as one
of those modules, because vendors of such gear have a great interest
to well define and expose all interfaces of such a device, wheras a typical
communications endpoint such as an application server in a data-center
is more often than not built around a business model where exposure/
definition of all interfaces would expose bad business practices.
Hence also political approaches like GDPR to start addressing
that problem.

Cheers
    Toerless

On Tue, Jan 28, 2020 at 10:02:43AM +0000, Stephen Farrell wrote:
> TLS, IPsec). Changing the security properties of widely
> deployed cryptographic protocols is not likely to be a
> useful approach to attempt, as there are too many
> deleterious side-effects of such proposed changes."
> 
> Cheers,

pub   RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) <[email-masked]>
> sub   RSA 4096/36CB8BB6 2017-12-22
> 

-- 
---
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Jan 2020 19:33:50 +0000

John, Kathleen,

Just on comments related to participation: "Participation
in this program is open to all interested parties, and
considered analysis of diverse inputs is important" is
what [1] already says. If you think some rewording is
needed be good to know what, or if it's just a case of
that text not having been noticed, then we're good I
guess.

Cheers,
S.

PS: I fixed the typo in the subject line that was my
fault in the first place:-)

[1]

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Jan 2020 19:39:11 +0000

Hiya

Offlist for two reasons...

> I totally do not get how you read Eliots text as being about TLS.

He and I have chatted about this before - one of the
options he maybe like for his train example is a NULL
encryption ciphersuite to be standardised/recommended
(as opposed to defined) for TLS1.3. I think that'd be
a bad plan.

> I read Eliot/Watsons mails to be in the same direction as what i was

2nd reason for offlist is that I'm not getting what you
mean below, but I'm pushed for time right now, so maybe
reading it later will make it clear;-) In any case, it'll
be a while 'till I get to respond, sorry.

Cheers,
S.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 28 Jan 2020 20:46:38 +0100

> On 28 Jan 2020, at 20:39, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya
> 

That is not my preferred solution, Stephen.  While industrial automation doesn’t really require encryption for most uses, I don’t think it can hurt, so long as the necessary auditing can take place.  Let’s focus on the problem first.  If we can agree on that, then let’s move on from there.

Eliot
> <0x5AB2FAF17B172BEA.asc>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Jan 2020 19:40:04 +0000

> Offlist for two reasons...

oops, sorry all, but no major harm done

S.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 28 Jan 2020 12:11:32 -0800

Hi Joel,
At 07:16 AM 28-01-2020, Joel M. Halpern wrote:
>application policy, business policy, or government policy.  To the 
>degree that these are decoupled from the technology we define, my 
>impression is that the IETF is neither skilled at nor influential 
>with regard to these topics. We can spend a lot of time and energy 
>on them.  They are interesting topics.  But are they really our business?

I'll reply to the question first.  The answer is no.

Application policy might be decoupled from, for example, 
regulations.  However, regulations can have an impact on how the 
application works.  I agree that the IETF is neither skilled nor does 
it have any influence on those topics.  That is applicable if the 
intention of this (IAB) effort is to have something similar to what 
is done in an IETF WG.

Regards,
S. Moonesamy

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 28 Jan 2020 15:52:26 -0500

> that text not having been noticed, then we're good I

That's very good, but I'm not sure how that community is feeling, it would
be good to make sure they know their participation is welcome. Perhaps a
message about this posted to SMART to redirect to this list would be
helpful.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 28 Jan 2020 14:50:08 -0800

Eliot --

The examples you describe are difficult to capture within protocol-specific
threat models (RFC 3552) or privacy considerations (RFC 6973).  For
practicality, those analyses need to maintain a narrow focus, yet at the
same time we understand that systemic privacy and security issues can only
be understood when analyzing the system that a protocol is embedded in.  As
a result, even protocols that successfully address the original threat
models can be the source of major systemic vulnerabilities. For example, we
could not have expected the authors of RFC 1945 (HTTP 1.0) to have
anticipated the security and privacy problems arising from today's social
media implementations - some of which were discussed during the Internet
Privacy Workshop summarized in RFC 6462.

However, I do think that you're on to something important that is worth IAB
consideration.

It strikes me that in a number of the examples you cite the "endpoint" is
not acting in the interest of the "end user", at least in the sense
described in draft-iab-for-the-users.  As was noted in Section 4.2:

   In contrast, the Internet of Things (IoT) has not yet seen the
   emergence of a natural role for representing the needs of the end
   user.  Perhaps as a result of this, that ecosystem and its users face
   serious challenges.

For example, consider how some of the IoT behavior you describe might be
handled within a permission model implemented in a browser or a mobile
device:

1. Would a user grant permission to access to camera or microphone?   In
the example of the device that did not advertise that it contained a
microphone, presumably, the answer would be "no" (although the microphone
was not initially enabled so perhaps permission might not have been
requested).
2. Would the user grant permission to access personal information such as
location?  In the example of the device with embedded trackers, again the
user would probably not have granted access to location and other data
(although we know that location can easily be obtained in circumvention of
browser or mobile device protections).

---

From: Eliot Lear <[email-masked]>
Date: Wed, 29 Jan 2020 10:48:32 +0100

Hi Bernard and thanks for your valuable thoughts.

> On 28 Jan 2020, at 23:50, Bernard Aboba <[email-masked]> wrote:
> 
> Eliot --
> 
> The examples you describe are difficult to capture within protocol-specific threat models (RFC 3552) or privacy considerations (RFC 6973).  For practicality, those analyses need to maintain a narrow focus, yet at the same time we understand that systemic privacy and security issues can only be understood when analyzing the system that a protocol is embedded in.  As a result, even protocols that successfully address the original threat models can be the source of major systemic vulnerabilities. For example, we could not have expected the authors of RFC 1945 (HTTP 1.0) to have anticipated the security and privacy problems arising from today's social media implementations - some of which were discussed during the Internet Privacy Workshop summarized in RFC 6462. 

I really cannot say what, if any, protocol changes I would suggest at this point to handle some of the cases I mentioned.  Assuming there is interest in this approach, I would suggest a bit of a collection and a culling.

I want to address one related point: Joel doesn’t think the program should get up into layer 9 too much, and I would say that it would be necessary to do so to figure out where we as a community want to make some Lessiguesque law, and when perhaps we need to leave that to others, but see below.

> 
> However, I do think that you're on to something important that is worth IAB consideration. 
> 
> It strikes me that in a number of the examples you cite the "endpoint" is not acting in the interest of the "end user", at least in the sense described in draft-iab-for-the-users.  As was noted in Section 4.2:
> 
> For example, consider how some of the IoT behavior you describe might be handled within a permission model implemented in a browser or a mobile device: 
> 
> 1. Would a user grant permission to access to camera or microphone?   In the example of the device that did not advertise that it contained a microphone, presumably, the answer would be "no" (although the microphone was not initially enabled so perhaps permission might not have been requested). 
> 2. Would the user grant permission to access personal information such as location?  In the example of the device with embedded trackers, again the user would probably not have granted access to location and other data (although we know that location can easily be obtained in circumvention of browser or mobile device protections).
> 

Very well put.

I think that leads us into a bit of futuristic scenario planning about how that permission model would work, what the control points are, then how they interact, etc.  The L9 discussions come in the form, I think, of incentive modeling to address the for-the-users point.  But that’s for later.  For now, what are the problems?

To Toerless’ point:

> Yes, i think we can agree that we would like all Internet end-to-end
> transport must not even allow for a misconfigured option to use null
> encryption, but i think when TLS 1.3 was standardized, there should have
> been a better solution than to completely oppress the needs of those
> other use-cases.

And my suggestion is that we take three steps back before we even go there.  Let’s not treat this like an IETF working group, but pause and take deep breaths and work the problem space just a bit.

Eliot

---

From: Jari Arkko <[email-masked]>
Date: Wed, 29 Jan 2020 18:48:04 +0100

Brian,

> generic threat model, which it wasn’t.

I agree of course. This is a small part of 3552. We are only considering
trends in the world that may affect that small part.

> together in Murray Hill, NJ). A good idea, but not a program.

Perhaps, but it is worth stating that at least from my perspective the
concept of an IAB program has differed depending on the topic at hand,
and perhaps more importantly, has evolved over time. Right now the
topics under consideration are mostly entirely open. This is fitting for the
two topics that we have brought up, but it is also at least in my impression
a shift in thinking, for openness obviously but also maybe bit of short term
goal of addressing a specific issue vs. very long-running programs. The
experiences from the latter haven’t always been promising.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 29 Jan 2020 18:53:30 +0100

SM,

> My preference would be to have the initial discussion of an RFC 3552 update within the IETF instead of this venue.  This would avoid the awkwardness of having to offer text to the IETF.

I think both me and Stephen are open to all kinds of organisational models :-) so it wouldn’t be too hard to convince us that we need something else instead. But we have heard the feedback that not having any organisation hurts the effort. Creating an IAB program is quite easy for us, some of the people who care about this topic are in the IAB and discussed it originally in the IAB. And if it gets a background/justification document done and makes a proposal, I think that should be considered a success. I don’t feel particular awkwardness with offering text to the IETF, they can obviously do whatever they want with that. YMMV but clearly, final decisions lie with the IETF community no matter what.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 29 Jan 2020 18:59:39 +0100

It occurs to me that Stephen and I made some assumptions that were not made explicit, and this has lead to some of the questions we’ve received. Perhaps it would be useful to be more explicit. In particular, we really want to extend the threat model, not take away anything that already exists, or start to reconsider the hugely important role of comsec. 

Maybe this change would better describe the scope:

OLD:

The model-t program provides an open venue for analysis of the
Internet threat model and has as a goal to produce a potential update
to BCP72 that defines an Internet threat model that better matches
today's reality.

NEW:

The model-t program provides an open venue for analysis of the
Internet threat model and has as a goal to produce a potential update
to BCP72 that defines an Internet threat model that better matches
today's reality. Specifically, the intent is to document why an update is
needed and provide a suggested update that could be considered by the
IETF. A potential BCP72 update would likely extend the set of threats
considered. Reducing the protection offered by current comsec
mechanisms is a non-goal. Similarly, re-consideration of the parts
of BCP72 that are outside the very narrow part on Internet threat
model is not in scope.

Jari

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 29 Jan 2020 20:14:28 +0100

Thanks, Jari

Now i read from the text you a) want more security not less, but
that you b) do not want to expand the scope outside the Internet
thread model, which i read from BCP72 section 3/3.1 as being about
secure point to point transport connections (*), maybe with secure
discovery/naming of the peer, but not including any multi-hop transitive
security of distributed applications such as web-proxies. Right ?
section 3.1 doesn't really shine on defining a clear model to
scope the Internet thread model.

How about the transitive security of systems like DNS or BGP ? And
if thats in scope, then why not web proxies or other distributed
applications ? (there are feasible answers, but those answers
would have to be part of a BCP72bis better explanation of the
thread model, and if the answers are as i think, then so too would
be security considerations of SDN controllers).

I think the charter scope you would like to see would be easier
explained by providing also two examples: something in-scope and
missing in BCP72, and an example that just barely is outside the
scope of your intended charter.

Cheers
    Toerless

On Wed, Jan 29, 2020 at 06:59:39PM +0100, Jari Arkko wrote:
> It occurs to me that Stephen and I made some assumptions that were not made explicit, and this has lead to some of the questions we???ve received. Perhaps it would be useful to be more explicit. In particular, we really want to extend the threat model, not take away anything that already exists, or start to reconsider the hugely important role of comsec. 
> 

-- 
---
[email-masked]

---

From: Robin Wilton <[email-masked]>
Date: Wed, 29 Jan 2020 21:17:38 +0000

Thanks, both. As I read your comments, one phrase kept presenting itself to me...
“user agency”. What is it, in the system, that is giving effect to the user’s intention and preferences. I’m not even going to try and guess which layer(s) that thing (or those things) reside, at this point, and I entirely agree that this is an opportunity to take a few deep breaths and consider the problem space.

Best wishes,
Robin
________________________________
From: Eliot Lear <[email-masked]>
Sent: Wednesday, January 29, 2020 9:48:32 AM
To: Bernard Aboba <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; Toerless Eckert <[email-masked]>
Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution

On 28 Jan 2020, at 23:50, Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:

Eliot --

Very well put.

To Toerless’ point:

Eliot

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Thu, 30 Jan 2020 11:42:11 +0700

Dear Mr. Wilton and architecture-discuss,

"User", "agency", "intentions" and "preferences" and "system": do phrases
made by those words  refer to, exemplified by the Web operation, networks
of languages...?

"The Internet works because of interoperability between different
computers, despite different hardware, operating systems, local language
context, and software supplier. Users of the web sign on to the use of
these languages when they use the Internet".
 (Tim Berners-Lee, "Stack of Specifications" in "Design Issues:
Architectural and Philosophical Points)

That was ever to be part of the discussion:
Re: [arch-d] Fwd: New Version Notification for
draft-iab-for-the-users-01.txt (December 15th 2019) (2)

Note:
(1) https://w3.org/DesignIssues/Stack.html

That to which I so far understand that:
In network societies, an individual/person is a synthesis, or a conflict
domain, of networks of things/languages with/for/to/among which s/he
celebrates/affirmes her/his life/existence...

(2)
https://mailarchive.ietf.org/arch/msg/architecture-discuss/7LSyY0nB_HyPPRdBkLpfmd5joeQ

Regard,
Guntur Wiseno Putra

Pada Kamis, 30 Januari 2020, Robin Wilton <[email-masked]> menulis:

> “user agency”. What is it, in the system, that is giving effect to the
> user’s intention and preferences. I’m not even going to try and guess which
> layer(s) that thing (or those things) reside, at this point, and I entirely
> agree that this is an opportunity to take a few deep breaths and consider
> the problem space.
>
> Best wishes,
> Robin
> ------------------------------
> *From:* Eliot Lear <[email-masked]>
> *Sent:* Wednesday, January 29, 2020 9:48:32 AM
> *To:* Bernard Aboba <[email-masked]>
> *Cc:* [email-masked] <[email-masked]>;
> [email-masked] <[email-masked]>; Toerless Eckert <[email-masked]>
> *Subject:* Re: [Model-t] [arch-d] Possible new IAB program on Internet
> trust model evolution
>
> The examples you describe are difficult to capture within
> protocol-specific threat models (RFC 3552) or privacy considerations (RFC
> 6973).  For practicality, those analyses need to maintain a narrow focus,
> yet at the same time we understand that systemic privacy and security
> issues can only be understood when analyzing the system that a protocol is
> embedded in.  As a result, even protocols that successfully address the
> original threat models can be the source of major systemic vulnerabilities.
> For example, we could not have expected the authors of RFC 1945 (HTTP 1.0)
> to have anticipated the security and privacy problems arising from today's
> social media implementations - some of which were discussed during the
> Internet Privacy Workshop summarized in RFC 6462.
>
>
> I really cannot say what, if any, protocol changes I would suggest at this
> point to handle some of the cases I mentioned.  Assuming there is interest
> in this approach, I would suggest a bit of a collection and a culling.
>
> I want to address one related point: Joel doesn’t think the program should
> get up into layer 9 too much, and I would say that it would be necessary to
> do so to figure out where we as a community want to make some Lessiguesque
> law, and when perhaps we need to leave that to others, but see below.
>
>
> I think that leads us into a bit of futuristic scenario planning about how
> that permission model would work, what the control points are, *then* how
> they interact, etc.  The L9 discussions come in the form, I think, of
> incentive modeling to address the for-the-users point.  But that’s for
> later.  For now, what are the problems?
>
> To Toerless’ point:
>
> And my suggestion is that we take three steps back before we even go
> there.  Let’s not treat this like an IETF working group, but pause and take
> deep breaths and work the problem space just a bit.
>
> Eliot
>
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 30 Jan 2020 07:48:37 +0100

Hi Robin

> On 29 Jan 2020, at 22:17, Robin Wilton <[email-masked]> wrote:
> 
> “user agency”. What is it, in the system, that is giving effect to the user’s intention and preferences.

Good point.

I was going to write out an example of how this would play out, but I am beginning to wonder if an I-D would do better, so as to memorialize a bit better the discussion.  This assumes it’s where the IAB wants to go.

Eliot

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Thu, 30 Jan 2020 14:11:23 +0700

To add the note I made in the previous message:

An Individual/person, by network society with ICTs as a structural matrix,
is a momentous synthesis, or a conflict domain --there may be still existed
conflicts accompanying her/his choices of acts--, of networks of
things/languages with/for/to/among which s/he celebrates/affirmes her/his
life/existence...

I am referring to notions on "Network Society" and "Networks of Languages"
worked in:

- "Informationalism, Technology and Network Society" (Manuel Catells)

https://annenberg.usc.edu/sites/default/files/2015/04/28/Informationalism%2C%20Networks%20and%20the%20Network%20Society.pdf

- here, it may deserve to note that in its forweword to "Leveraging
Tech..." report Antonio Gueterez beginned with the term "networked society"

"Our networked society is changing the way we live. The impact and
implications
of the digital revolution are becoming more evident with each passing hour.

The 2030 Agenda for Sustainable Development recognizes the great potential
of global connectivity to spur human progress. It challenges us to ensure
universal and affordable Internet access for all".

- J. F. Lyotard, "The Postmodern Conditions: a Report on Knowledge" section
"Elementary Nature of Social Ties: Posmodern Perspective" as there was
mentioned about society defined by "networks of language"

Regard,
Guntur Wiseno Putra

Pada Kamis, 30 Januari 2020, Eliot Lear <[email-masked]> menulis:

> user’s intention and preferences.
>
> Good point.
>
> I was going to write out an example of how this would play out, but I am
> beginning to wonder if an I-D would do better, so as to memorialize a bit
> better the discussion.  This assumes it’s where the IAB wants to go.
>
> Eliot
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 30 Jan 2020 07:31:42 -0800

> There is relatively broad agreement that the roles and trustwortiness
> of different endpoints in a protocol exchange are important
> considerations. In specific cases there may be quite different
> perspectives on the tradeoffs involved, e.g., to what extent privacy,
> information centralisation, or the needs of enterprise networks should
> be considered as the highest priority. And no doubt, other equally
> valid perspectives exist.

Actually, it's not clear to me that *any* of these are valid
things to put in a threat model. Recall what 3552 says a threat
model is:

   A THREAT MODEL describes the capabilities that an attacker is assumed
   to be able to deploy against a resource.  It should contain such
   information as the resources available to an attacker in terms of
   information, computing capability, and control of the system.  The
   purpose of a threat model is twofold.  First, we wish to identify the
   threats we are concerned with.  Second, we wish to rule some threats
   explicitly out of scope.  Nearly every security system is vulnerable
   to a sufficiently dedicated and resourceful attacker.

But none of the things you list are really part of a threat model.

Rather, they are weights one applies to various design considerations,
but that's a consideration but that's a form of analysis that happens
*after* you have a threat model, not part of the threat model itself.
For instance, I don't think anyone thinks that privacy threats (e.g.,
traffic analysis) aren't part of our threat model (and they're clearly
part of the 3552 threat model). Now, as a matter of protocol design,
we have often opted not to do much about these threats for practical
reasons, but that's a different matter.

As Brian said, the purpose of 3552 is to force protocol designers
to describe the security properties of their protocols and the purpose
the threat model section is to provide a common starting point for
that analysis. IOW, it is an essentially tutorial function So to the
extent to which an update for 3552 is needed, its purpose should be to
make clear considerations which aren't otherwise obvious from the text
in 3552. But that's not about a new threat model or about balancing
but rather about documentation.

-Ekr

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Sat, 1 Feb 2020 12:07:04 +0700

Parts concerning with "the Internet security" today at Internet Society:

Internet Society 2020 Action Plan

- We believe deeply that the Internet must be open, globally-connected,
secure, and trustworthy.

- In 2020, we will continue to work towards realizing our vision by
building, promoting, and defending a bigger and stronger Internet.

 II. Strengthening the Internet

-- Promoting the Internet way of networking

-- Extending encryption

-- Securing global routing

-- Increasing time security

-- Leading by example with open standards and protocols

https://www.internetsociety.org/action-plan/2020/

2020 Action Plan Projects

Strengthening the Internet

- Internet Way of Networking
- Encryption
- Securing Global Routing (MANRS)
- Time Security
- Open Standards Everywhere

https://www.internetsociety.org/action-plan/2020/projects/

Regard,
Guntur Wiseno Putra

Pada Kamis, 30 Januari 2020, Eric Rescorla <[email-masked]> menulis:

> For instance, I don't think anyone thinks that privacy threats (e..g.,