Subject: Re: [Model-t] [email-masked] list description

From: Michael Richardson <[email-masked]>
Date: Thu, 1 Aug 2019 11:28:57 -0400

On 2019-07-29 4:44 p.m., Stephen Farrell wrote:
> 
> Hiya,
> 
> This is mostly to start to populate the archive but the list
> description for this list is:
> 
> "The model-t list is for discussions of changes in Internet

I notice the repeated capital-I Internet.
There are often different situations for LLNs, Data-Centers, and the like.

Is the point of this list to talk about threats on the Internet,
or about better explaining threat models assumed in documents,
such that we have better Security Considerations?
The tasks are not mutually exclusive.  Being better able to say, 
"mechanism X deals with the Internet Threat model situation Y"
is a great win for Security Considerations.

At first reading, I thought it was more about articulating threat models 
better, but upon further reading, I think this list is more about 
specific threats.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 1 Aug 2019 16:52:13 +0100

Hiya,

Could you hold and re-tx that question in a few days?

I'd like to leave some time for folks to get subscribed
to the list so's we don't end up having to re-do things
or get too far ahead of people who mightn't have had a
chance to join the list immediately.

As I said on the saag list, when I see enough of the
folks I recall commenting in the mic lines (and other
usual suspects:-) have subscribed, I'll send an "off
we go" mail to the list, at which point please re-tx.

Ta,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 2 Aug 2019 15:33:52 +0100

Hiya,

> I notice the repeated capital-I Internet.

Habit more than anything in my case at least. I wouldn't read
too much into it.

> There are often different situations for LLNs, Data-Centers, and the like.

Sure. Those are not IMO out of scope at all. But neither is
any one of those the full scope - I think the scope we ought
consider here is basically any network technology that the
IETF does/controls/specifies and even a bit more than that,
as IETF-defined things can of course be attacked from lower
layers or physically etc.

> better, but upon further reading, I think this list is more about

I'm not sure I'm quite getting what you mean exactly. FWIW,
I do think we'll be discussing threats on this list, but a
useful output will be a distillation of that discussion that
gives us the kind of win for security considerations you have
in quotes above.

Cheers,
S.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Fri, 2 Aug 2019 10:39:12 -0400

> Habit more than anything in my case at least. I wouldn't read

I remember recently writing "internet" into a draft and was taught that RFC
4949 says the following (while emphasizing that it's not official IETF
position or anything)... I realize this is a small thing but would love to
know if there are other authorities here:

   $ internet, Internet
      1. (I) /not capitalized/ Abbreviation of "internetwork".

      2. (I) /capitalized/ The Internet is the single, interconnected,
      worldwide system of commercial, governmental, educational, and
      other computer networks that share (a) the protocol suite
      specified by the IAB (RFC 2026
<https://tools.ietf.org/html/rfc2026>) and (b) the name and address
      spaces managed by the ICANN. (See: Internet Layer, Internet
      Protocol Suite.)

      Usage: Use with definite article ("the") when using as a noun. For
      example, say "My LAN is small, but the Internet is large." Don't
      say "My LAN is small, but Internet is large."

https://tools.ietf.org/html/rfc4949

-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Michael Richardson <[email-masked]>
Date: Fri, 02 Aug 2019 13:58:25 -0400

> Sure. Those are not IMO out of scope at all. But neither is any one of
    > those the full scope - I think the scope we ought consider here is
    > basically any network technology that the IETF does/controls/specifies
    > and even a bit more than that, as IETF-defined things can of course be
    > attacked from lower layers or physically etc.

What I'm trying to say is that there are some threats that we deal with
on the Capital-Internet that are far more manageable in the small.

We then get into trouble when someone takes a DC technology and uses it
across the Internet, or when the DC becomes multi-tenant, etc.

    >> Is the point of this list to talk about threats on the Internet, or
    >> about better explaining threat models assumed in documents, such that
    >> we have better Security Considerations?  The tasks are not mutually
    >> exclusive.  Being better able to say, "mechanism X deals with the
    >> Internet Threat model situation Y" is a great win for Security
    >> Considerations.
    >>
    >> At first reading, I thought it was more about articulating threat
    >> models better, but upon further reading, I think this list is more
    >> about specific threats.

    > I'm not sure I'm quite getting what you mean exactly. FWIW, I do think
    > we'll be discussing threats on this list, but a useful output will be a
    > distillation of that discussion that gives us the kind of win for
    > security considerations you have in quotes above.

For instance, https://datatracker.ietf.org/doc/rfc7416/ provides a list of
threats to LLNs.   Having named them, I don't have to repeat them in other
documents.  That's really useful.

AFAIK, we don't (yet?) have an IETF document that details the problem with
predictable/guesstable IDs, such as DNS query IDs or TCP SYN numbers.
{yes, Fernando has a document that goes that way}.  Does that threat have a name?
Does the name change based upon whether the attacker is on-path (able to
observe traffic), or off-path?  Naming such things would be useful.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

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

---

From: "Martin Thomson" <[email-masked]>
Date: Sat, 03 Aug 2019 13:18:16 +1000

> on the Capital-Internet that are far more manageable in the small.

Like a red rag to a bull...

I don't think that this is a sustainable attitude.  If we are going to take security seriously, we have to consider every networked device to be exposed to a hostile environment.  Now that doesn't mean that you can't take steps to limit hostility in networks, and there might be sound reasons to believe that the degree to which you have to expend resources in defense of certain attacks is different as a result.  But the notion of a gooey middle remains a big part of the problem statement.

This isn't really on-topic for this list as I understand it, and I wasn't planning to say much here until someone said this.  Sorry Michael :)

---

From: Bret Jordan <[email-masked]>
Date: Fri, 2 Aug 2019 22:24:29 -0600

To borrow your words…  “If we are going to take security seriously”…  we need to understand and document the full attack surface.  So let us start listing them out.  Here are four.

Attack: Active remote attack
Exposure: Full compromise of system and data
Client Knowledge: Potential indicators may be visible
Protection Possibilities: Deploy both client and network level protections
Headwinds: Client based protections are usually inadequate
Severity: High
Kill-Chain Phase: Lateral Movement 

Attack: Active in-band attack
Exposure; Full compromise of system and data
Client Knowledge: Potential indicators may be visible
Protection Possibilities: Deploy both client and network level protections, user awareness training, content and DNS filtering
Headwinds: Client based protections are usually inadequate
Severity: High
Kill-Chain Phase: Delivery and Exploitation 

Attack: Passive monitoring of traffic
Exposure: Information about where traffic is going and potentially details of the content being shared 
Client Knowledge: No, it is very hard to detect passive monitoring tools
Protection Possibilities: Encrypt traffic 
Headwinds: Global adoption of better encryption
Severity: Low
Kill-Chain Phase: Reconnaissance

Attack: Active in-band monitoring and tracking 
Exposure: Information about what the user is doing and where they are going 
Client Knowledge: Generally no 
Protection Possibilities: Client and network level protections
Headwinds: Some clients are making it hard to deploy client side protections 
Severity: Low
Kill-Chain Phase: Reconnaissance

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

> On Aug 2, 2019, at 9:18 PM, Martin Thomson <[email-masked]> wrote:
> 
> Model-t mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/model-t

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 3 Aug 2019 14:22:30 +0100

On 03/08/2019 04:18, Martin Thomson wrote:
> This isn't really on-topic for this list as I understand it,

Why?

FWIW, I think we'll be better off if the discussion roams
a lot at first so I'd argue that the discussion of the
historical approach of hard boundary/goey middle is defo
in scope as is how one might do better. (I'm not claiming
that in the end we can "fix" that but trying is in scope
I'd say.)

S.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 3 Aug 2019 14:33:26 +0100

Hiya,

Two things:

- I'm not sure how applicable stix and other information model
type approaches might be for addressing an Internet threat model,
but that seems like a topic that'd deserve a thread or two...

- I generally like the attack surface metaphor and find it useful
in thinking about security when making changes to a specific
system or network. So that metaphor could certainly be useful.
I'm not sure though that there is such a thing as "the full
attack surface" that can be usefully enumerated.

Thanks,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 3 Aug 2019 07:25:52 -0700

Bret,

I'm having a fair amount of trouble understanding what these attacks you
are referring to mean. Perhaps you could lay them out in more detail?

-Ekr

On Fri, Aug 2, 2019 at 9:24 PM Bret Jordan <[email-masked]> wrote:

> To borrow your words…  “If we are going to take security seriously”…  we
> need to understand and document the full attack surface.  So let us start
> listing them out.  Here are four.
>
>
> Protection Possibilities: Deploy both client and network level
> protections, user awareness training, content and DNS filtering
> I don't think that this is a sustainable attitude.  If we are going to
> take security seriously, we have to consider every networked device to be
> exposed to a hostile environment.  Now that doesn't mean that you can't
> take steps to limit hostility in networks, and there might be sound reasons
> to believe that the degree to which you have to expend resources in defense
> of certain attacks is different as a result.  But the notion of a gooey
> middle remains a big part of the problem statement.
>
> This isn't really on-topic for this list as I understand it, and I wasn't
> planning to say much here until someone said this.  Sorry Michael :)
>
> --
> Model-t mailing list
> [email-masked]

---

From: Bret Jordan <[email-masked]>
Date: Sat, 3 Aug 2019 08:37:09 -0600

I did not use anything from STIX. Are you referring to the use of kill chain phase? 

Bret 

Sent from my Commodore 64

> On Aug 3, 2019, at 7:33 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
> Two things:
> 
> <0x5AB2FAF17B172BEA.asc>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 3 Aug 2019 15:40:21 +0100

> I did not use anything from STIX. Are you referring to the use of
I was. If you're using some other methodology be interested
in which. (Those information model based approaches to
describing threats/incidents aren't something I follow in
detail.)

Cheers,
S.

---

From: Jim Fenton <[email-masked]>
Date: Sat, 3 Aug 2019 09:52:43 -0700

On 8/2/19 9:24 PM, Bret Jordan wrote:

> To borrow your words…  “If we are going to take security seriously”…
>  we need to understand and document the full attack surface.  So let
> us start listing them out.  Here are four.
>
>

[etc.]

Perhaps we need to decide what we consider a threat model to be. I see
Bret's list as a collection of specific attacks (tactics), while I
consider a threat model to be at a higher level than that, e.g., whether
nation-states, or supply chain threats, should be part of that model.

When I was working on the draft that became RFC 4686 (DKIM Threat
Analysis), Russ Housley gave me some very good coaching about how to
structure that. He suggested that it should describe:

- The nature and location of the bad actors
- What the bad actors' capabilities are
- What they intend to accomplish via their attacks

How do we want to define threat model?

-Jim

---

From: Ted Lemon <[email-masked]>
Date: Sat, 3 Aug 2019 13:12:03 -0400

Yes. It would also be good to avoid domain-specific jargon. Presumably the goal here is to provide something of value to the whole community, not something that only people who are familiar with a very specific vernacular can use. 

Of course, I might be mistaken about the intended scope of this work, so if this sounds wrong it would be good to get consensus on that. 

Sent from my iPhone

> On Aug 3, 2019, at 12:52 PM, Jim Fenton <[email-masked]> wrote:
>

---

From: Bret Jordan <[email-masked]>
Date: Sat, 3 Aug 2019 11:26:04 -0600

Stephen,

While there are several minor variations on the “Kill Chain” as defined originally by Lockheed Martin in the following paper back in 2011 I think (https://www.lockheedmartin.com/content/dam/lockheed-martin/rms/documents/cyber/LM-White-Paper-Intel-Driven-Defense.pdf <https://www.lockheedmartin.com/content/dam/lockheed-martin/rms/documents/cyber/LM-White-Paper-Intel-Driven-Defense.pdf>).

In addition, MITRE has recently produced an ATT&CK framework to help identify and characterize threat actor behavior.  NIST has already produced a Cyber Security Framework that is commonly used when talking about these sorts of things. 

STIX on the other hand is a taxonomy for sharing threat intelligence.  Things like threat actors, campaigns, intrusion sets, attack patterns, malware information, indicators of compromise, etc etc.

Thanks,
Bret

> On Aug 3, 2019, at 8:40 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
>

---

From: Bret Jordan <[email-masked]>
Date: Sat, 3 Aug 2019 11:28:13 -0600

Jim,

They are not specific attacks, but rather categories of attacks that could be executed by any number of threat actors.  Some threat actors may have different capabilities or different levels of sophistication, but in general, these types of attacks are not specific to a certain classification of threat actor. 

Thanks,
Bret

> On Aug 3, 2019, at 10:52 AM, Jim Fenton <[email-masked]> wrote:
>

---

From: Bret Jordan <[email-masked]>
Date: Sat, 3 Aug 2019 11:39:43 -0600

Ted,

This is not jargon, this is the language that is used in this space. If we are going to write a document or come up with text to help improve a document that deals with this domain, then we should probably know and understand the domain. Attacks against network connected devices (endpoints, network equipment, IoT devices, etc) are all in scope.  So when we work on designing solutions for interconnected systems, we need to understand this space.  Designing technologies without taking this space into consideration is very problematic.  

We have many in this group that work in this space and have very detailed knowledge of it.  If you have specific questions, I am sure many of us would be willing to help fill in the gaps.  

IMO, the key to our work is to help improve the IETF’s understanding of risks, threat actor TTPs, attack surface, etc.  This space has evolved a lot recently, and has definitely changed since 3552 was first written.  Further, given the upcoming market shift to 5G enabled devices and its changing attack surface, this work is prudent at this time.  Gone are the days of “Escargot Model” (a term I started using back in the late 80s / early 90s) of security. 

Thanks,
Bret

> On Aug 3, 2019, at 11:12 AM, Ted Lemon <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 3 Aug 2019 18:47:51 +0100

Hiya,

On 03/08/2019 18:39, Bret Jordan wrote:
> This is not jargon, this is the language that is used in this space.

I agree that these kinds of information model based approaches
are fairly widely used by those dealing with specific incidents
and products/services that in some way deal with specific incidents.

But it's less clear if or how those approaches apply at protocol
design time, which is what's more relevant here. I think the
applicability may be even less clear for protocols that are used
in widely different contexts. It's also unclear (to me anyway)
how or if privacy issues could be addressed with such approaches.

However, I can imagine a case for approaches like these could well
be made, and I'd be interested in seeing that attempted as part
of this discussion.

Hopefully someone'll start a new thread for that with some kind
of overview/proposal like that,

Cheers,
S.

---

From: Christian Huitema <[email-masked]>
Date: Sat, 3 Aug 2019 11:09:24 -0700

On 8/3/2019 10:47 AM, Stephen Farrell wrote:
> how or if privacy issues could be addressed with such approaches

Reading this thread, I think that we are missing a step. We cannot
define attacks without defining first the assets that need to be
protected. Different actors probably have different views on that, such as:

1) Continuous operation of the Internet

2) Continuous operation of a specific Internet provider

3) Continuous availability of an Internet Service

4) Continuous connectivity for a given user

5) Protection of databases used by services and enterprises

6) Protection of the personal data of users

Do we have agreement on what we are trying to protect?

-- Christian Huitema

---

From: Watson Ladd <[email-masked]>
Date: Sat, 3 Aug 2019 11:21:14 -0700

How on earth do I write a Security Consideration section that
addresses that sort of high level thing?
What does this methodology produce?

When we look at actual vulnerabilities with CVE numbers attached, and
go back we don't see "active remote attack". We see using C is a bad
idea. Look at programs doing what the users didn't want, and the
answer isn't DNS filtering, it's sandboxing. Where is that in your
list of answers? Attacks like "Johnny You're Fired" have a cause:
overly complicated file formats with lots of edge cases.  These are
problems that some of which the IETF can't solve but some where a
better threat model and understanding of security would have solved.

At the same time we see problems like Amazon's architecture around VM
authentication not respecting traditional Unix permission models
because it makes credentials available over HTTP from the machine. So
if you take a standard sort of setup and move it to the cloud, you now
can have a problem sometimes called SSRF, but really just another
Confused Deputy. I believe this was discovered on MULTICS.

We need to have a model that gets people answering the right question,
not the wrong one. And a threat taxonomy at the high level just says
there are bad people online. We know that. That's the problem. How do
we stop them from doing what they want? Well, that's where computer
security comes in, and the goal has to be to recognize the security
properties we want, and ensure the systems we have have those
properties. And the threat model informs what the properties are. It
doesn't matter how big the system. It doesn't matter if it's accessed
by pigeon, phone, microwave link, or 5G. It doesn't even need to be
made of silicon: HFDF was an anonymity attack resulting in location
detection at the PHY layer, as was identifying telegraph operators by
their fist.

On Sat, Aug 3, 2019 at 10:26 AM Bret Jordan <[email-masked]> wrote:
>
> Stephen,
>
> While there are several minor variations on the “Kill Chain” as defined originally by Lockheed Martin in the following paper back in 2011 I think (https://www.lockheedmartin.com/content/dam/lockheed-martin/rms/documents/cyber/LM-White-Paper-Intel-Driven-Defense.pdf).
>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 3 Aug 2019 20:23:03 +0200

> 4) Continuous connectivity for a given user

These all appear to be availability objectives.

> 5) Protection of databases used by services and enterprises

This could be integrity or confidentiality or both.

> 6) Protection of the personal data of users

This appears to be a confidentiality objective.
(The actual data protection objective is only partially a security objective.)

> Do we have agreement on what we are trying to protect?

There also other kinds of objectives, such as accountability, third party verifiability (“non-reputation”), anonymity, etc.

Essentially you need to build a cross-product of the objects (assets) and the kinds of objectives you have for them to really know what needs to be protected.  There also are derived (secondary) objectives, e.g. to maintain the integrity of a password-protected system you need to confidentiality-protect the passwords.

And then there are the motivations and capabilities of the attackers.  These tend to shift very dynamically to the weakest point in the defense, so the landscape of capabilities is hard to describe in a lasting way.  The underlying motivations are a bit more stable.

Grüße, Carsten

---

From: Ted Lemon <[email-masked]>
Date: Sat, 3 Aug 2019 14:37:38 -0400

Bret, I appreciate that this is a special area of technical expertise and that it has a domain-specific vocabulary. That is what the word “jargon” means. 

The reason I raised this concern is not that I can’t go out and learn this jargon. It’s that if the goal of this effort is to help the IETF to do a better job of reasoning about threats, the IETF has to be able to understand the output. 

There is already great work going on in this space amongst the experts. If this is to just be another such effort, I don’t think it will accomplish your stated goals.  So I’m being deliberately pedantic here because I would like to see the output of this effort actually change how the IETF reasons about threats. That’s going to require some foundational documents. The fact that you didn’t point me at an RFC or draft to answer my question tells me that I’m not wrong to be concerned. 

Sent from my iPhone

> On Aug 3, 2019, at 1:39 PM, Bret Jordan <[email-masked]> wrote:
> 
> Ted,
>

---

From: Bret Jordan <[email-masked]>
Date: Sat, 3 Aug 2019 15:47:13 -0600

Protection of end users’ data

Protection of an organization’s data

Protection of devices owned by an end user or an organization 

Protection of network equipment 

Protection of SCADA system

Protection of critical infrastructure 

Protection of IoT and soon to be released 5G devices 

Protection of cost optimized controllers

The problem we have had in the past is we want to call this one of the following, but each one does not encompass the full picture.
1) Computer security
2) Data security 
3) Information security 
4) Communication security 
5) Network security 
6) Application security 
Etc, etc, 

So if you way we are just dealing with communication security or information security we are missing a significant piece of the pie. 

Thanks,
Bret

---

From: Bret Jordan <[email-masked]>
Date: Sat, 3 Aug 2019 15:58:03 -0600

I fully agree that there will need to be some foundational documents written to help the IETF as a whole come up to speed.  

We are basically in the same boat with cyber in the IETF as we are with crypto. If you do not know what key material, or a Nonce, or how asymmetric differs from symmetric algorithms, or how the discrete logarithm problem compares to prime factorization, you will be lost.  So the crypto side of the IETF uses a lot of jargon, as well.  But it is domain specific vernacular. This cyber side also has a lost of very well known and understood terms.  I am sure ENISA, NIST, and even the ITU have great resources.  ISC^2 and SANS also have a lot of material about this space. 

What we are trying to do now is help the IETF realize that it is more than just communication security and information security.  The market just happens to call this bigger umbrella "cyber security".  But I know many here do not like that term, even if the industry does use it.  Trying to break the problem down to just one of the sub parts is where we fall over and where we get in trouble. 

Thanks,
Bret

> On Aug 3, 2019, at 12:37 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Aug 3, 2019, at 1:39 PM, Bret Jordan <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Ted,
>> 
>>> On Aug 3, 2019, at 11:12 AM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>> On Aug 3, 2019, at 12:52 PM, Jim Fenton <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> [email-masked] <mailto:[email-masked]>
>>>> https://www.iab.org/mailman/listinfo/model-t <https://www.iab.org/mailman/listinfo/model-t>
>>

---

From: Watson Ladd <[email-masked]>
Date: Sat, 3 Aug 2019 15:14:33 -0700

Could you point to an issue with IETF work where this "cyber" language
is useful and would have lead to insights that would have avoided the
issue? That might help illuminate why it is actually productive.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 3 Aug 2019 22:08:04 -0700

his seems like a reasonable problem statement for the overall problem of
computer security, but not really for IETF.

To take a concrete example memory reading attacks like Spectre are a threat
to user data and something that browser vendors spend a fair amount of
energy working on, but they're mostly not in scope for IETF [0]. There's
nothing wrong with that, it's just division of labor.

-Ekr

[0] I say "mostly" because (a) we need to take the security implications of
these kinds of attacks in our protocol designs and (b) there might be some
small pieces of IETF work like CORB, though that seems to be mostly being
done elsewhere.

On Sat, Aug 3, 2019 at 2:47 PM Bret Jordan <[email-masked]> wrote:

> The problem we have had in the past is we want to call this one of the
> following, but each one does not encompass the full picture.
> 1) Computer security
> 2) Data security
> 3) Information security
> So if you way we are just dealing with communication security or
> information security we are missing a significant piece of the pie.
>
>
> Thanks,
> Bret

---

From: Dominique Lazanski <[email-masked]>
Date: Sun, 4 Aug 2019 08:14:14 +0100

> On 4 Aug 2019, at 06:08, Eric Rescorla <[email-masked]> wrote:
> 
> his seems like a reasonable problem statement for the overall problem of computer security, but not really for IETF.
> 

But computer security is Internet security. It is rare that ‘things’ are not connected to the Internet  (with the exception of intranets however the same type of devices are connected to both). 

If some attacks are initiated at the pint of ‘things’ in order to compromise the Internet I don’t see why this shouldn’t be in scope?

FWIW I think Christian and Bret’s emails outline issues that should be included in scope. 

> To take a concrete example memory reading attacks like Spectre are a threat to user data and something that browser vendors spend a fair amount of energy working on, but they're mostly not in scope for IETF [0]. There's nothing wrong with that, it's just division of labor.
> 
> -Ekr
> 
> [0] I say "mostly" because (a) we need to take the security implications of these kinds of attacks in our protocol designs and (b) there might be some small pieces of IETF work like CORB, though that seems to be mostly being done elsewhere.
> 
>>> protected.. Different actors probably have different views on that, such as:
>>>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 4 Aug 2019 02:09:50 -0700

On Sun, Aug 4, 2019 at 12:14 AM Dominique Lazanski <[email-masked]>
wrote:

> But computer security is Internet security. It is rare that ‘things’ are
> not connected to the Internet  (with the exception of intranets however the
> same type of devices are connected to both).
>
> If some attacks are initiated at the pint of ‘things’ in order to
> compromise the Internet I don’t see why this shouldn’t be in scope?
>

Well, I didn't say anything about "things" one way or the other.

However, my point is that while compromise of endpoints necessarily
negatively affects the Internet, actually protecting those endpoints
against compromise is outside the scope of the IETF. That's not to say it's
not important, it's just not IETF work. To provide two examples perhaps
closer to home:

- Even though compromise of the Web is bad for the Internet, the IETF has
largely punted the security of the Web itself to W3C and WHATWG.
- Compromise of the WebPKI would obviously be very bad for many protocols
the IETF has designed, but the management of the WebPKI is done by CABF,
not IETF.

-Ekr

> To take a concrete example memory reading attacks like Spectre are a
> threat to user data and something that browser vendors spend a fair amount
> of energy working on, but they're mostly not in scope for IETF [0]. There's
> [0] I say "mostly" because (a) we need to take the security implications
> of these kinds of attacks in our protocol designs and (b) there might be
> some small pieces of IETF work like CORB, though that seems to be mostly
> being done elsewhere.
>

---

From: Dominique Lazanski <[email-masked]>
Date: Sun, 4 Aug 2019 10:49:07 +0100

> On 4 Aug 2019, at 10:09, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
>> On Sun, Aug 4, 2019 at 12:14 AM Dominique Lazanski <[email-masked]> wrote:
>> 
>> 
> However, my point is that while compromise of endpoints necessarily negatively affects the Internet, actually protecting those endpoints against compromise is outside the scope of the IETF. That's not to say it's not important, it's just not IETF work. To provide two examples perhaps closer to home:

I disagree. Any issue that impacts the Internet should be considered. 

> 
> - Even though compromise of the Web is bad for the Internet, the IETF has largely punted the security of the Web itself to W3C and WHATWG.

Times are changing! 

> - Compromise of the WebPKI would obviously be very bad for many protocols the IETF has designed, but the management of the WebPKI is done by CABF, not IETF.

But that’s the whole point of this group and discussion is to think about all the issues and the changes and the wider problems that are happening. I’d rather look at everything and narrow the scope of and when necessary. All three Internet drafts on this subject so far even acknowledge that. 

> -Ekr
-dml

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 4 Aug 2019 11:37:06 +0100

Hiya,

> nothing wrong with that, it's just division of labor.

I tend to agree.

OTOH, one might also wonder if such attacks are or ought be
considered in NFV and similar things. Such wonderings could
I think be useful, even if the answer is maybe that without
the flexibility of JS a successful attack in such a scenario
seems unlikely enough to not have to (currently) bother with.
(That said, I've not really considered it in any detail so
maybe these attacks are more relevant for NFV and co than
I might think - anyone know?)

A bit later...

On 04/08/2019 10:09, Eric Rescorla wrote:
> - Compromise of the WebPKI would obviously be very bad
> for many protocols the IETF has designed, but the management
> of the WebPKI is done by CABF, not IETF.

That's also true, but nonetheless the IETF did document CT
as a direct result of the WebPKI CAs doing a bad job wrt
mis-issuance risks. So while "replace CABF, because <X>"
would not be a sensible outcome of this discussion, it's
reasonable to not consider the current WebPKI as a fixed
unchangeable thing, for the purposes of this discussion.
Now, as it happens, I don't think we're likely to need to
delve much into CABF's space (or the RPKI operators
similarly) in this discussion, except maybe if we're
considering when or how new PKIs might or might not be a
good idea.

S.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 4 Aug 2019 04:14:35 -0700

On Sun, Aug 4, 2019 at 3:37 AM Stephen Farrell <[email-masked]>
wrote:

> threat

That's true in the Web context, but not in other contexts, such as virtual
hosting. Indeed, cross-VM attacks go back even before Spectre, at least to,
Ristenpart et al. 2009
https://hovav.net/ucsd/papers/rtss09.html.

> unchangeable thing, for the purposes of this discussion.

i don't disagree with this. My point was merely that this is an example of
deciding that certain technical work was out of scope.

-Ekr

---

From: Bret Jordan <[email-masked]>
Date: Sun, 4 Aug 2019 09:40:09 -0600

I agree here with Dominique. 

More specifically, we need to understand that types of attacks that impact clients and how those attacks take advantage of the overall weakness of clients. Doing this will help us better design protocols.  We need to stop saying that clients are secure or even worse, kicking the can down the road and not worrying about it. 

In a previous email I called out 4 high level types of attacks that impact users data, users privacy, and the overall integrity of endpoints. 

Thanks,
Bret

> On Aug 4, 2019, at 3:49 AM, Dominique Lazanski <[email-masked]> wrote:
> 
> 
> 
> On 4 Aug 2019, at 10:09, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> 
>> 
>> On Sun, Aug 4, 2019 at 12:14 AM Dominique Lazanski <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> On 4 Aug 2019, at 06:08, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On Sat, Aug 3, 2019 at 2:47 PM Bret Jordan <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Watson Ladd <[email-masked]>
Date: Sun, 4 Aug 2019 08:53:28 -0700

But we design protocol, we don't design clients. Ultimately any
product has to be useful for the IETF, and should result in changes to
how people think.

Efforts to end the use of bearer tokens, forward secrecy, etc. are
very much motivated by a model where a client system can be
compromised. I don't think that model is unknown, although perhaps it
should be added explicitly.

I can definitely think of issues that are "endpoint" issues where
protocols have fallen short (my Amazon and Johnny examples) due to the
mismatch between the Internet and Unix, and these are threats that
generally have fallen out of scope. (NFS permissions issues are
another example of this)

---

From: Ted Lemon <[email-masked]>
Date: Sun, 4 Aug 2019 11:00:01 -0500

If the point of this effort is to document threat models, then we aren’t writing protocols at least here. It’s probably useful if the threat models we produce describe things we don’t built, because they interact with things we do build. 

Sent from my iPhone

> On Aug 4, 2019, at 10:53 AM, Watson Ladd <[email-masked]> wrote:
>

---

From: Dominique Lazanski <[email-masked]>
Date: Sun, 4 Aug 2019 17:12:45 +0100

I agree with Ted and Brett. 

Worse case scenario is that we document too much and decide later that we are going to narrow the scope. But to start let’s include everything. 

-dml

> On 4 Aug 2019, at 17:00, Ted Lemon <[email-masked]> wrote:
>

---

From: Bret Jordan <[email-masked]>
Date: Sun, 4 Aug 2019 10:37:03 -0600

I full agree Ted.  We need to ensure everyone here in the IETF understands the bigger problem, the larger risk, and larger attack surface.  When we design protocols and only consider a small handful of threats, then we inevitably hurt the market.  

The more of these things we can document and the more we can bring them to light, the better everything will be in the end. 

Thanks,
Bret

> On Aug 4, 2019, at 10:00 AM, Ted Lemon <[email-masked]> wrote:
> 
> On Aug 4, 2019, at 10:53 AM, Watson Ladd <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Sun, Aug 4, 2019 at 8:40 AM Bret Jordan <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> On Aug 4, 2019, at 3:49 AM, Dominique Lazanski <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>>

---

From: Bret Jordan <[email-masked]>
Date: Sun, 4 Aug 2019 10:43:57 -0600

Yes, we should include everything up front.  Then later on, we can group and categorize ideas and concepts together. 

Thanks,
Bret

> On Aug 4, 2019, at 10:12 AM, Dominique Lazanski <[email-masked]> wrote:
> 
> On 4 Aug 2019, at 17:00, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 4 Aug 2019 12:11:49 -0500

> The more of these things we can document and the more we can bring them to light, the better everything will be in the end. 

Of course, wearing my IETF pedant hat, we do need to be careful not to try to boil the ocean.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 4 Aug 2019 22:23:01 +0100

Partly agreeing, partly quibbling:-)

On 04/08/2019 17:37, Bret Jordan wrote:
> We need to ensure everyone here in the IETF understands the bigger
> problem, 

It is certain that not every IETF participant will care about
understanding every detail of every possible threat. They do
have other things do be doing:-)

> the larger risk, and larger attack surface.  When we design
> protocols and only consider a small handful of threats, then we
> inevitably hurt the market.

IMO we ought not only think in terms of "the market" - I'd
hope rather that everyone sometimes thinks of more than commerce
as the Internet impacts on people in other ways that are
relevant in this discussion.

> The more of these things we can document and the more we can bring
> them to light, the better everything will be in the end.
Yes, but it's important to document things in a way that can
lead up to then winnowing things down to something that ends
up useful to that population of IETFers who are not security
or privacy specialists.

Cheers,
S.

---

From: Bret Jordan <[email-masked]>
Date: Sun, 4 Aug 2019 16:32:59 -0600

I do not want to boil the ocean.  As we work through this, we can figure out the right balance for this community and other communities that will need to look at and reference our work.

Thanks,
Bret

> On Aug 4, 2019, at 11:11 AM, Ted Lemon <[email-masked]> wrote:
> 
> On Aug 4, 2019, at 11:37 AM, Bret Jordan <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Bret Jordan <[email-masked]>
Date: Sun, 4 Aug 2019 16:38:23 -0600

A few comments inline… Sorry, I try not to do that. 

Thanks,
Bret

> On Aug 4, 2019, at 3:23 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 

I fully agree.  We need to make sure the documentation we come up with is super easy to understand, is easily digestible, but yet covers enough of the problem space, that it is really meaningful. 

> relevant in this discussion.

Sorry bad word choice.  =~s/market/industry/g;  When I refer to “the market” I am not talking about the vendor space, commercial space, or the sell stuff over the web space.  I am simply referring to the way end users, organizations, enterprises, and governments need to use the connectedness of computers and IP address ranges to do what ever it is they are doing. So I should have said “industry” or if you have a better term, let me know.  

> up useful to that population of IETFers who are not security

Once again, I fully agree.  But we need to start somewhere.  The Stanford D-School has a great set of classes on how to effectively brainstorm.  And I think that is what we are trying to do now.  We are trying to get the discussion going and get everything out there, so we can start to better understand how big the elephant is that we need to work on. 

Bret

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 5 Aug 2019 00:00:05 +0100

Hiya,

> A few comments inline… Sorry, I try not to do that.

Why not? It's fine. (And easier to follow in mail I believe.)

>> IMO we ought not only think in terms of "the market" - I'd hope
>> rather that everyone sometimes thinks of more than commerce as the
>> Internet impacts on people in other ways that are relevant in this
>> discussion.
> 
> Sorry bad word choice.  =~s/market/industry/g;  When I refer to “the
> market” I am not talking about the vendor space, commercial space, or
> the sell stuff over the web space.  I am simply referring to the way
> end users, organizations, enterprises, and governments need to use
> the connectedness of computers and IP address ranges to do what ever
> it is they are doing. So I should have said “industry” or if you have
> a better term, let me know.

I suspect this is one where we're better to recognise that
nobody's fav term is correct;-) It's entirely legit to consider
how security/privacy analyses affect the market, and how they
affect society, and how they affect specific communities, and how
they affect the set of people who use or care about the Internet.
Those are all valid, as would be other sets of interested parties,
and I suspect we'd never reach consensus as to the relative
importance of each. I think if we each accept that other folks
rate those differently for reasons that are possibly as valid as
our own, that might be good enough.

>>> The more of these things we can document and the more we can
>>> bring them to light, the better everything will be in the end.
>> Yes, but it's important to document things in a way that can lead
>> up to then winnowing things down to something that ends up useful
>> to that population of IETFers who are not security or privacy
>> specialists.
> 
> Once again, I fully agree.  But we need to start somewhere.  The
> Stanford D-School has a great set of classes on how to effectively
> brainstorm.  And I think that is what we are trying to do now.  We
> are trying to get the discussion going and get everything out there,
> so we can start to better understand how big the elephant is that we
> need to work on

The elephant metaphor isn't my favourite. Even if we're each
scrambling around in the dark, there might not be exactly one
elephant. In this case, I think there definitely is more than
one. For example, we have the enterprise n/w vs big-I security
differences, and we also have the commercial/govt surveillance
vs. human rights/freedom differences. It may be my lack of
imagination but I can't see how those are part of one elephant.
(And I think that's true regardless of one's opinions as to any
of the locally-perceived potential elephant parts:-)

Cheers,
S.

> 
> Bret
> 
> 
>> 
>> Cheers, S. <0x5AB2FAF17B172BEA.asc>
> 
> 
>

---

From: Bret Jordan <[email-masked]>
Date: Sun, 4 Aug 2019 17:25:30 -0600

This is why I listed four types of attacks and what is at risk with them.  We have to start somewhere.

Recopying here:

Thanks,
Bret

> On Aug 4, 2019, at 5:00 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 5 Aug 2019 00:31:24 +0100

Hiya,

On 05/08/2019 00:25, Bret Jordan wrote:
> This is why I listed four types of attacks and what is at risk with
> them.  

I gotta admit I do not get your argument there. It could be
one of many. Maybe if you could be patient and spell it out
...

TIA,
S.

> We have to start somewhere.>
> Recopying here:
> 
> Attack: Active remote attack Exposure: Full compromise of system and
> data Client Knowledge: Potential indicators may be visible Protection
> Possibilities: Deploy both client and network level protections 
> Headwinds: Client based protections are usually inadequate Severity:
> High Kill-Chain Phase: Lateral Movement
> 
> Attack: Active in-band attack Exposure; Full compromise of system and
> data Client Knowledge: Potential indicators may be visible Protection
> Possibilities: Deploy both client and network level protections, user
> awareness training, content and DNS filtering Headwinds: Client based
> protections are usually inadequate Severity: High Kill-Chain Phase:
> Delivery and Exploitation
> 
> Attack: Passive monitoring of traffic Exposure: Information about
> where traffic is going and potentially details of the content being
> shared Client Knowledge: No, it is very hard to detect passive
> monitoring tools Protection Possibilities: Encrypt traffic Headwinds:
> Global adoption of better encryption Severity: Low Kill-Chain Phase:
> Reconnaissance
> 
> Attack: Active in-band monitoring and tracking Exposure: Information
> about what the user is doing and where they are going Client
> Knowledge: Generally no Protection Possibilities: Client and network
> level protections Headwinds: Some clients are making it hard to
> deploy client side protections Severity: Low Kill-Chain Phase:
> Reconnaissance
> 
> 
> 
> Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8
> ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however,
> the only thing that can not be unscrambled is an egg."
> 
>>>>> protocols and only consider a small handful of threats, then
>>>>> we inevitably hurt the market.
>>>> 
>>>> hope rather that everyone sometimes thinks of more than
>>>> commerce as the Internet impacts on people in other ways that
>>>> are relevant in this discussion.
>>> 
>>> Sorry bad word choice.  =~s/market/industry/g;  When I refer to
>>> “the market” I am not talking about the vendor space, commercial
>>> space, or the sell stuff over the web space.  I am simply
>>> referring to the way end users, organizations, enterprises, and
>>> governments need to use the connectedness of computers and IP
>>> address ranges to do what ever it is they are doing. So I should
>>> have said “industry” or if you have a better term, let me know.
>> 
>> I suspect this is one where we're better to recognise that nobody's
>> fav term is correct;-) It's entirely legit to consider how
>> security/privacy analyses affect the market, and how they affect
>> society, and how they affect specific communities, and how they
>> affect the set of people who use or care about the Internet. Those
>> are all valid, as would be other sets of interested parties, and I
>> suspect we'd never reach consensus as to the relative importance of
>> each. I think if we each accept that other folks rate those
>> differently for reasons that are possibly as valid as our own, that
>> might be good enough.
>> 
>>>> lead up to then winnowing things down to something that ends up
>>>> useful to that population of IETFers who are not security or
>>>> privacy specialists.
>>> 
>>> Stanford D-School has a great set of classes on how to
>>> effectively brainstorm.  And I think that is what we are trying
>>> to do now.  We are trying to get the discussion going and get
>>> everything out there, so we can start to better understand how
>>> big the elephant is that we need to work on
>> 
>> elephant. In this case, I think there definitely is more than one.
>> For example, we have the enterprise n/w vs big-I security 
>> differences, and we also have the commercial/govt surveillance vs.
>> human rights/freedom differences. It may be my lack of imagination
>> but I can't see how those are part of one elephant. (And I think
>> that's true regardless of one's opinions as to any of the
>> locally-perceived potential elephant parts:-)
>> 
>> Cheers, S.
>> 
>> 
>>> 
>>> Bret
>>> 
>>> 
>>>>

---

From: Christian Huitema <[email-masked]>
Date: Sun, 4 Aug 2019 22:52:19 -0700

On 8/4/2019 2:09 AM, Eric Rescorla wrote:

> On Sun, Aug 4, 2019 at 12:14 AM Dominique Lazanski
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>>     his seems like a reasonable problem statement for the overall
>>     problem of computer security, but not really for IETF.
>>
>
>     But computer security is Internet security. It is rare that
>     ‘things’ are not connected to the Internet  (with the exception of
>     intranets however the same type of devices are connected to both). 
>
> against compromise is outside the scope of the IETF. That's not to say
> it's not important, it's just not IETF work. To provide two examples
> perhaps closer to home:
>
> - Even though compromise of the Web is bad for the Internet, the IETF
> has largely punted the security of the Web itself to W3C and WHATWG.
> - Compromise of the WebPKI would obviously be very bad for many
> protocols the IETF has designed, but the management of the WebPKI is
> done by CABF, not IETF.

In my previous job, we were routinely doing lots of threat modelling. (I
you think of smart-ass comments about target rich environments you
should rather consider the rich target that we have in front of us.) The
main lesson is that you should be organized, and not just rush to
listing a bunch of attacks. The steps we pretty much agreed on were
relatively simple:

1) List the assets that you do want to protect.

2) Get an architecture diagram of the system, and from that look at the
interfaces that could be used for attacks

3) Brainstorm a list of the attacks you can think of on these interfaces

4) Check whether these attacks can be reasonably mitigated, and if they
cannot think harder. Or at least document known vulnerabilities.

Eric, I get your point about the limited scope of the IETF. There are
obviously attacks that are out of scope for us, such as identifying
users by the radio signatures of their mobile devices or creatively
using JavaScript in a web page for fun and profit. The IEEE or the 3GPP
might do something on the first one, the W3C may do something about the
other, and still other organizations may address other problems. But it
does not follow that we should not start by listing the assets that we
want to protect. For example, mobile user location privacy or generally
Internet user privacy are assets in our model, even if we cannot
possibly be the sole keepers of the fortress.

So we need pruning at some point. But I think that pruning should come
at the second stage: identify the interfaces through which the assets
can be attacked. In my example, we should not consider the radio level
interface or even the JavaScript API as interfaces that we worry about.
With one caveat, though. We know by experience that clients, servers and
routers can be pwned. This is an avenue of attack against other Internet
access, as shown in recent attacks that use penetration of a DNS
provider server to attack clients of that server. We may want to look at
these kind of "network based dependencies" when we enumerate the interfaces.

-- Christian Huitema

---

From: Ted Lemon <[email-masked]>
Date: Mon, 5 Aug 2019 06:50:38 -0700

I think this is a great approach, Christian.   If we follow your model we should be able to start from what we know and avoid boiling the ocean, without inappropriately skipping some modeling that we actually need to do because it borders on our space, even though it is not itself our space.

There are a few other things I think we should do.

First, you may have noticed that I don’t actually show a clear understanding of what the goals of this effort are in my comments.   This is because I’m a security area consumer more than a security area producer, so I wasn’t in the saag meeting.  I saw Stephen’s mail go by about “security models” and thought to myself “excellent, we need that.”   That’s literally all I know about what the plan is for this discussion.   It would be good to actually write down what our goals are.

Second, I don’t think we all agree on how we want to describe threat models.   If there is to be an abbreviated form for describing threats (as opposed to natural English) we need to document what that form is in sufficient detail that IETF participants who are not SMEs can understand it, and hopefully even contribute.   I’m not saying we have to write an RFC, but at a minimum there should be a wiki that has the needed information.

I also don’t think we even agree on what we mean by threat models.   Of course we mean models of threats, but at what level of detail?   How close to the code are these models?  How general, or how specific?   This may all be obvious to people on this list who are SMEs, but I’m not, so for me it would help to describe what we mean by “threat model,” not because anybody here is unclear on the basic concept, but because I suspect we don’t agree on the particulars.

As an example, the models that Bret has described don’t seem as if they would be helpful to me.  This doesn’t mean that they aren’t right—it either means that I don’t understand them clearly, or that we simply have different requirements.   It may be that what I want is not what should be produced here—I’m not claiming otherwise.   But it would be good to get some clarity on that.

---

From: Bret Jordan <[email-masked]>
Date: Mon, 5 Aug 2019 07:58:39 -0600

Here is an I-D that some might find helpful as we talk about this problem and how we best solve it.  https://tools.ietf.org/html/draft-taddei-smart-cless-introduction-00 <https://tools.ietf.org/html/draft-taddei-smart-cless-introduction-00>

Thanks,
Bret

---

From: Bret Jordan <[email-masked]>
Date: Mon, 5 Aug 2019 08:07:46 -0600

I agree with you Ted, this is something we need.  We just need to work through the details to help make sure everyone understands this problem.  We also need to figure out a way to document this material in a way that everyone can understand, but does not cut the information off at the knees.  Too often I feel like we have historically narrowed this information down to statisfy our own confirmation bias. 

I fully get that many here do not understand the attack lifecycle at the same level or understand what an intrusion set is and how that relates to threat actor techniques, tactics, and procedures (or their modus operandi). I also know that most here probably do not track threat actor activity.  But some of us do.  We need to bring some of this knowledge and expertise in to the IETF to help insure that we design things that improve overall security for end users on the internet.

Thanks,
Bret

> On Aug 5, 2019, at 7:50 AM, Ted Lemon <[email-masked]> wrote:
>

---

From: Christian Huitema <[email-masked]>
Date: Mon, 5 Aug 2019 08:10:21 -0700

> On Aug 5, 2019, at 7:07 AM, Bret Jordan <[email-masked]> wrote:
> 

I am sure that some of us do understand the struggle against progressive penetration of organizations networks and eventual looting of customer data and corporate secrets. On the other hand, the IETF is not going to opine on specific techniques like isolation of credentials or monitoring active directory servers, or on the signal to noise ratio of intrusion detection systems. I want to wait until we have an actual list of goals and assets, but I suspect that we will need limits.

Some things might be in scope, though. Many of the penetration attacks start with phishing campaigns, using either web access or email. And SMTP is probably in scope. But phishing through social networks would not be.

-- Christian Huitema

---

From: Bret Jordan <[email-masked]>
Date: Mon, 5 Aug 2019 09:32:59 -0600

Here is another good document that was written by a friend of mine.

https://tools.ietf.org/html/draft-lazanski-smart-users-internet-00 <https://tools.ietf.org/html/draft-lazanski-smart-users-internet-00>

Thanks,
Bret

> On Aug 5, 2019, at 7:58 AM, Bret Jordan <[email-masked]> wrote:
>

---

From: Bret Jordan <[email-masked]>
Date: Mon, 5 Aug 2019 09:41:31 -0600

As I have illustrated, the 4 attack groups cover these general high level attacks that everyone on the internet faces. These are things that I think we CAN do something about. 

I am not suggesting that we should talk about specific instances or specific types of attacks.  Those would be things like how threat actor FOO compromises layer 2 cache on the CPU to jump between virtual machines in cloud provider.  Or how threat actor bar attacks specific IoT devices from a compromised data center in some geo-center to finally launch an attack against a nation’s power grid.  While some of these attacks are interesting and very elaborate in nature.  They are not in scope. 

1) Attacking the system directly.

2) Delivering an attack through a user initiated session or exfiltrating data through said session

4) Passive monitoring of all traffic

5) Monitoring and tracking all user's traffic inside their session. 

Thanks,
Bret

> On Aug 5, 2019, at 9:10 AM, Christian Huitema <[email-masked]> wrote:
> 
> 
> 
>

---

From: Watson Ladd <[email-masked]>
Date: Mon, 5 Aug 2019 08:58:20 -0700

On Mon, Aug 5, 2019, 8:41 AM Bret Jordan <[email-masked]> wrote:

> As I have illustrated, the 4 attack groups cover these general high level
> attacks that everyone on the internet faces. These are things that I think
> we CAN do something about.
>

What do you concretely propose we change in an existing protocol to deal
with them and how does the threat model lead to that? Can this threat model
do that?

> I am not suggesting that we should talk about specific instances or
> specific types of attacks.  Those would be things like how threat actor FOO
> compromises layer 2 cache on the CPU to jump between virtual machines in
> cloud provider.  Or how threat actor bar attacks specific IoT devices from
> a compromised data center in some geo-center to finally launch an attack
> against a nation’s power grid.  While some of these attacks are interesting
> and very elaborate in nature.  They are not in scope.
>

They are in scope insofar as capabilities they have derive from failures of
systems to provide security properties.

> 1) Attacking the system directly.

What can the IETF do against this one?

> data through said session

What's an attack? How do we e.g. stop the latest UAF against $BROWSER? Some
of these bugs are real fun, but I don't know what any standards body can do
about them.

> 5) Monitoring and tracking all user's traffic inside their session.

What happened to confused deputies etc? This is so high level I don't see
how to get security properties out.

Fundamentally the bolt on security model is kaput. I don't disagree we
should expand the threat model but it needs to be a model of attacker
capabilities, not behavior, and goals that we want systems to meet.

I think it's realistic to have a model where U2F looks like a good idea to
stop phishing because users are not good at password management. I think
it's also reasonable to have a model where privacy risks of third party
cookies/other similar models are discussed. But "attacks"? I don't know how
to think about "attacks".

> I fully get that many here do not understand the attack lifecycle at the
> same level or understand what an intrusion set is and how that relates to
> threat actor techniques, tactics, and procedures (or their modus operandi).
> I also know that most here probably do not track threat actor activity.
> But some of us do.  We need to bring some of this knowledge and expertise
> in to the IETF to help insure that we design things that improve overall
> security for end users on the internet.
>
>
> I am sure that some of us do understand the struggle against progressive
> penetration of organizations networks and eventual looting of customer data
> and corporate secrets. On the other hand, the IETF is not going to opine on
> specific techniques like isolation of credentials or monitoring active
> directory servers, or on the signal to noise ratio of intrusion detection
> systems. I want to wait until we have an actual list of goals and assets,
> but I suspect that we will need limits.
>
> Some things might be in scope, though. Many of the penetration attacks
> start with phishing campaigns, using either web access or email. And SMTP
> is probably in scope. But phishing through social networks would not be.
>
> -- Christian Huitema
> --
> Model-t mailing list
> [email-masked]