Subject: [Model-t] w3c also thinking about threat models

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Sep 2019 11:26:35 +0100

Hiya,

Hope we all had a nice summer break from this
discussion, but I'd like to try see if we can
get back at it, so I've added reviewing the
various drafts folks have posted to my todo
list - I hope to send some comments/reviews
in the next week-ish.

In the meantime, it looks like w3c are also
thinking about threat models [1] which is
interesting.

Cheers,
S.

[1] https://github.com/w3cping/privacy-threat-model

---

From: Dominique Lazanski <[email-masked]>
Date: Fri, 20 Sep 2019 18:12:14 +0100

> On 20 Sep 2019, at 11:26, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

Thanks for kick starting this list again especially after the summer!

Interesting W3C work, but I would add that they are only looking at privacy threat models so they have that covered. Perhaps we should look at system security threat models since W3C has kicked off their work specifically on privacy. That way we can be more holistic about the work.

Looking forward to the discussions.

Dominique

---

From: Bret Jordan <[email-masked]>
Date: Fri, 20 Sep 2019 11:48:41 -0600

Yes, privacy is just one facet. 

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 Sep 20, 2019, at 11:12 AM, Dominique Lazanski <[email-masked]> wrote:
> 
> 
> 
> -- 
> Model-t mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/model-t

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Sep 2019 21:01:43 +0100

> Yes, privacy is just one facet. 

Sure, it's clearly true that privacy is not everything
in the IETF context, nor in w3c either. I guess the
argument for putting more focus on privacy in w3c might
be that the web has a reasonably worked out, (even if
imperfect) security model (the SOP etc), but that the
web has been pretty awful for privacy. Well, that's an
argument I'd make, not sure if the people involved in
the w3c work would:-)

S.

---

From: Bret Jordan <[email-masked]>
Date: Mon, 23 Sep 2019 08:41:35 -0600

> the web has a reasonably worked out security model 

Given how nearly all attacks, campaigns, malware, and intrusion sets use the web or software connecting to the web to either compromise victims, exfiltrate personal or private information from victims, or destroy victims’ information I think one could easily argue that your statement that there is "a reasonably worked out security model" is false. 

Thanks,
Bret

> On Sep 20, 2019, at 2:01 PM, Stephen Farrell <[email-masked]> wrote:
> 
> <0x5AB2FAF17B172BEA.asc>

---

From: Watson Ladd <[email-masked]>
Date: Mon, 23 Sep 2019 07:51:54 -0700

On Mon, Sep 23, 2019, 7:41 AM Bret Jordan <[email-masked]> wrote:

> Given how nearly all attacks, campaigns, malware, and intrusion sets use
> the web or software connecting to the web to either compromise victims,
> exfiltrate personal or private information from victims, or destroy
> victims’ information I think one could easily argue that your statement
> that there is "a reasonably worked out security model" is false.
>

An RCE vulnerability due to memory safety issues isn't a a result of not
thinking about the security model.

> Interesting W3C work, but I would add that they are only looking at
> privacy threat models so they have that covered. Perhaps we should look at
> system security threat models since W3C has kicked off their work
> specifically on privacy. That way we can be more holistic about the work.
>

---

From: Bret Jordan <[email-masked]>
Date: Mon, 23 Sep 2019 09:18:20 -0600

There are a lot more problem than an "RCE vulnerability due to memory safety issues". This response, IMO, is part of the problem.  We keep trying to tie things to a single thing.  The attack surface and security model is much much broader. 

Thanks,
Bret

> On Sep 23, 2019, at 8:51 AM, Watson Ladd <[email-masked]> wrote:
> 
> 
> 
> On Mon, Sep 23, 2019, 7:41 AM Bret Jordan <[email-masked] <mailto:[email-masked]>> wrote:
> An RCE vulnerability due to memory safety issues isn't a a result of not thinking about the security model.
> 
> 
> 
> 
> Thanks,
> Bret
>> On Sep 20, 2019, at 2:01 PM, Stephen Farrell <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>> On Sep 20, 2019, at 11:12 AM, Dominique Lazanski <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On 20 Sep 2019, at 11:26, Stephen Farrell <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 
>>>>> 
>>>>> Hiya,
>>>>> 
>>>> [email-masked] <mailto:[email-masked]>
>>>> https://www.iab.org/mailman/listinfo/model-t <https://www.iab.org/mailman/listinfo/model-t>
>>> 
>>> 
>>> 
>> <0x5AB2FAF17B172BEA.asc>
> 
> -- 
> Model-t mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.iab.org/mailman/listinfo/model-t <https://www.iab.org/mailman/listinfo/model-t>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Sep 2019 16:32:03 +0100

Bret,

On 23/09/2019 15:41, Bret Jordan wrote:

> Given how nearly all attacks, campaigns, malware, and intrusion sets
> use the web or software connecting to the web 

Malware (ab)using the web doesn't imply anything about
what might be right or wrong with the current web security
model though. Same as malware doing that doesn't imply
anything about the security model for IP, which is also
in use in almost all such cases.

I think that's an error that keeps cropping up in these
discussions that we might wanna try figure out some, i.e.,
(and generalising) if protocol-X can be abused for bad-thing-Y
in a way that's (from some vantage point) indistinguishable
from nominal use of protocol-X, then what does that say about
the threat model used to develop protocol-X? It might be
evidence that a better threat model would have resulted
in a better protocol-X, or, it might be due to a problem
with that vantage point (no longer) being a good place to
distinguish nominal behaviour vs. bad-thing-Y, for protocol-X.

In the case of the web, I think a lot of the issues raised
by folks like yourself seem to come down to the shift from
a cleartext to a ciphertext web changing the set of vantage
points from which one can (trivially) attempt to make such
distinctions.

That doesn't imply that the web security model is broken
though, given the set of trade-offs that have to be dealt
with. (And also given the set of IETF consensus positions
about e2e and not breaking crypto etc. that are relevant to
this discussion, if we want a successful outcome to bring
back into IETF-land.) Nor does that change mean that the set
of problems faced by enterprise networks are to be ignored,
but ISTM the current web security model and the practicalities
of changing that do constrain how one might sensibly go about
trying to improve the situation for users and operators of
such networks. (And I agree improvements are needed or I'd
not be interested in this discussion:-)

> to either compromise
> victims, 

Where web vulns are used as part of a compromise, then
yes, those indicate problems with the web security model.
Meaning the likes of XSS happens too easily etc. I guess
ideas to try improve those might mostly be better handled
in the W3C though, but discussing 'em here seems reasonable
as long as we keep that in mind.

> exfiltrate personal or private information from victims, or
> destroy victims’ information I think one could easily argue that your
> statement that there is "a reasonably worked out security model" is
> false.

Except that wasn't my statement, that's just a misquote.
What I said was "...a reasonably worked out, (even if
imperfect) security model (the SOP etc)..." after which
I bemoaned the privacy impacts of the current web;-)

Cheers,
S.

> 
> 
> 
> 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."
> 
>> Sure, it's clearly true that privacy is not everything in the IETF
>> context, nor in w3c either. I guess the argument for putting more
>> focus on privacy in w3c might be that the web has a reasonably
>> worked out, (even if imperfect) security model (the SOP etc), but
>> that the web has been pretty awful for privacy. Well, that's an 
>> argument I'd make, not sure if the people involved in the w3c work
>> would:-)
>> 
>> S.
>> 
>>> 
>>> 
>>> 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."
>>> 
>>>>> Hope we all had a nice summer break from this discussion, but
>>>>> I'd like to try see if we can get back at it, so I've added
>>>>> reviewing the various drafts folks have posted to my todo 
>>>>> list - I hope to send some comments/reviews in the next
>>>>> week-ish.
>>>>> 
>>>>> In the meantime, it looks like w3c are also thinking about
>>>>> threat models [1] which is interesting.
>>>>> 
>>>>> Cheers, S.
>>>> 
>>>> Interesting W3C work, but I would add that they are only
>>>> looking at privacy threat models so they have that covered.
>>>> Perhaps we should look at system security threat models since
>>>> W3C has kicked off their work specifically on privacy. That way
>>>> we can be more holistic about the work.
>>>> 
>>>> -- Model-t mailing list [email-masked]

---

From: Dominique Lazanski <[email-masked]>
Date: Mon, 23 Sep 2019 17:04:18 +0100

> On 23 Sep 2019, at 16:32, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Bret,
> 

FWIW it would be useful to be all inclusive with ideas and threats and then define what is in and out of scope for the threat model rather than limit the scope right away.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Sep 2019 17:17:47 +0100

Hiya,

On 23/09/2019 17:04, Dominique Lazanski wrote:
> FWIW it would be useful to be all inclusive with ideas and threats
> and then define what is in and out of scope for the threat model
> rather than limit the scope right away.
I'm not sure if I agree or disagree with that:-) That's
because I'm not sure what you're concerned might be out
of scope - can you clarify?

In case it helps, the scope for this list AIUI is as
described when the list was created after IETF105:

"The model-t list is for discussions of changes in Internet
deployment patterns and their impact on the Internet threat
model, and to develop advice for designing, implementing and
deploying Internet protocols in ways that account for these
changes. Output may eventually be contributed to the IETF
consensus process if the IETF believes an update to BCP 72/RFC
3552 is warranted and thus ought be consistent with related
IETF consensus positions, such as BCP 188 and BCP 200."

I think that's pretty broad, and means we can talk as much
as we want about things in this space, but a useful output
sorta has to be one that might get traction in the IETF as
some kind of modification of, or extension to, BCP72.

Cheers,
S.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 23 Sep 2019 07:45:29 -1000

> On Sep 23, 2019, at 5:32 AM, Stephen Farrell <[email-masked]> wrote:
> 
> Bret,
> 

Au contraire!

The past decades should have taught us that bug happens and are exploited. That's very relevant for the Internet threat model. If a server is exploited, will clients and further servers fall off like dominoes? What kind of defense in depth have we built in the architecture? How do we isolate nodes when they are faulty? What remediation strategies do we have available ?

You can apply this analysis to multiple subsystems. For example, if a name server is compromised, can the attackers gain access to the domains that it serves? Can they obtain certificates?

-- Christian Huitema

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 23 Sep 2019 14:07:05 -0400

It seems pretty clear to me that if we take the view that everything is 
in scope, we will not produce any useful improvements in our current 
security considerations in any reasonably measurable time.

It seems to follow that if we want useful results, we had best find 
somewhere to draw a line and agree that we will deal with some 
well-defined scope.

Of course, if all people want is a place to complain about the 
interaction of architecture, protocol, implementation, and underlying 
hardware flaws, I guess we can just complain forever.

Yours,
Joel

---

From: Watson Ladd <[email-masked]>
Date: Mon, 23 Sep 2019 12:26:39 -0700

> hardware flaws, I guess we can just complain forever.

Amen! But I think we can look at actual gaps in the network security model
vs the host security model vs what programmers and users expect etc. XSS
can be seen as a consequence of lacking quotation mechanisms in server
interpolated strings.

We also shouldn't privilege one use case over others.

> > The past decades should have taught us that bug happens and are
> exploited. That's very relevant for the Internet threat model. If a server
> is exploited, will clients and further servers fall off like dominoes? What
> kind of defense in depth have we built in the architecture? How do we
> isolate nodes when they are faulty? What remediation strategies do we have
> available ?
> >
> > You can apply this analysis to multiple subsystems. For example, if a
> name server is compromised, can the attackers gain access to the domains
> that it serves? Can they obtain certificates?
> >
> > -- Christian Huitema
> >
>
> --
> Model-t mailing list
> [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Sep 2019 20:44:32 +0100

Hiya,

On 23/09/2019 18:45, Christian Huitema wrote:
>>> Given how nearly all attacks, campaigns, malware, and intrusion
>>> sets use the web or software connecting to the web
>> 
>> Malware (ab)using the web doesn't imply anything about what might
>> be right or wrong with the current web security model though. Same
>> as malware doing that doesn't imply anything about the security
>> model for IP, which is also in use in almost all such cases.
> 
> Au contraire!
> 
> exploited. That's very relevant for the Internet threat model. If a
> server is exploited, will clients and further servers fall off like
> dominoes? What kind of defense in depth have we built in the
> architecture? How do we isolate nodes when they are faulty? What
> remediation strategies do we have available ?
> 
> name server is compromised, can the attackers gain access to the
> domains that it serves? Can they obtain certificates?

Sorry, I'm failing to see how what you say is contrary to
what I said above. Can you explain?

In case it helps: to clarify what I meant, ISTM the fact
that HTTPS can be (ab)used for C&C or exfiltration doesn't
mean that the threat model used in the design of HTTPS is
broken.

I also do agree that defence in depth is worth considering
in this discussion, in particular how to handle DNSpionage
and supply-chain type threats to which I guess you may be
referring.

But those two things don't seem to be in direct conflict
to me.

We may want to document threats like the latter so that
implementers and protocol designers can better consider
them, but that doesn't seem to imply anything much to
me about the goodness or otherwise of the web security
model.

Cheers,
S.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 23 Sep 2019 09:52:10 -1000

On 9/23/2019 9:26 AM, Watson Ladd wrote:
>
>
> On Mon, Sep 23, 2019, 11:07 AM Joel M. Halpern <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Amen! But I think we can look at actual gaps in the network security
> model vs the host security model vs what programmers and users expect
> etc. XSS can be seen as a consequence of lacking quotation mechanisms
> in server interpolated strings.
>

To answer Joel, I think there is a middle ground between "everything is
in scope" and "we don't worry about the implementation of the
endpoints". Clearly, we cannot address the multiple ways in which
endpoint security fails. On the other hand, we can accept the
possibility that endpoint security will sometimes fail, and incorporate
that in the threat model. Endpoint security failures often only affects
the endpoint itself, such as "get a virus, lose your files". I am not
proposing that the IETF discusses that. But many times, endpoint
security failures affect a number of other systems.

For example, we recently saw attacks in which the hackers gain
possession of one of the replicated DNS servers for a TLD, which allowed
them to put up a fake web server for a domain inside that TLD and
attempt to capture login credentials for users of that domain. The
attacks was not perfectly executed, but it seems that they could also
have obtained valid TLS certificates for that TLD using automated
services. Single point of failure, fairly bad results. If that is not in
scope for the revised threat model, what is?

-- Christian Huitema

---

From: Bret Jordan <[email-masked]>
Date: Mon, 23 Sep 2019 14:47:03 -0600

The security model needs to be more than just “can passive third parties see the traffic”. We need to make sure we understand and call out the operational security aspects of things we create here. 

Thanks,
Bret

> On Sep 23, 2019, at 1:52 PM, Christian Huitema <[email-masked]> wrote:
> 
> 
> 
>> On Mon, Sep 23, 2019, 11:07 AM Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
>> Amen! But I think we can look at actual gaps in the network security model vs the host security model vs what programmers and users expect etc. XSS can be seen as a consequence of lacking quotation mechanisms in server interpolated strings.
>> 
> To answer Joel, I think there is a middle ground between "everything is in scope" and "we don't worry about the implementation of the endpoints". Clearly, we cannot address the multiple ways in which endpoint security fails. On the other hand, we can accept the possibility that endpoint security will sometimes fail, and incorporate that in the threat model. Endpoint security failures often only affects the endpoint itself, such as "get a virus, lose your files". I am not proposing that the IETF discusses that. But many times, endpoint security failures affect a number of other systems. 
> 
> For example, we recently saw attacks in which the hackers gain possession of one of the replicated DNS servers for a TLD, which allowed them to put up a fake web server for a domain inside that TLD and attempt to capture login credentials for users of that domain. The attacks was not perfectly executed, but it seems that they could also have obtained valid TLS certificates for that TLD using automated services. Single point of failure, fairly bad results. If that is not in scope for the revised threat model, what is?
> 
> -- Christian Huitema
> 
> -- 
> Model-t mailing list
> [email-masked]

---

From: Watson Ladd <[email-masked]>
Date: Mon, 23 Sep 2019 15:42:27 -0700

On Mon, Sep 23, 2019, 1:47 PM Bret Jordan <[email-masked]> wrote:

> The security model needs to be more than just “can passive third parties
> see the traffic”. We need to make sure we understand and call out the
> operational security aspects of things we create here.
>

Is there a model for operational security? I thought the idea would be to
look at properties protocols and systems need to have to ensure security
properties we want to have in the face of threats, and where what we have
falls short.

It feels like we're going around in circles with people in the enterprise
thinking that you can bolt on a box to tell the bad from the good, and
others thinking you need to think carefully about what other kinds of boxes
can be bolted on, and pointing out the availability of MDM etc.

And if we're going to rethink threat models it should be more forward
looking then one particular methodology for cleaning up the limitations of
today's security models.

> To answer Joel, I think there is a middle ground between "everything is in
> scope" and "we don't worry about the implementation of the endpoints".
> Clearly, we cannot address the multiple ways in which endpoint security
> fails. On the other hand, we can accept the possibility that endpoint
> security will sometimes fail, and incorporate that in the threat model.
> Endpoint security failures often only affects the endpoint itself, such as
> "get a virus, lose your files". I am not proposing that the IETF discusses
> that. But many times, endpoint security failures affect a number of other
> systems.
>
> For example, we recently saw attacks in which the hackers gain possession
> of one of the replicated DNS servers for a TLD, which allowed them to put
> up a fake web server for a domain inside that TLD and attempt to capture
> login credentials for users of that domain. The attacks was not perfectly
> executed, but it seems that they could also have obtained valid TLS
> certificates for that TLD using automated services. Single point of
> failure, fairly bad results. If that is not in scope for the revised threat
> model, what is?
>
> -- Christian Huitema
> --
> Model-t mailing list
> [email-masked]