Re: [Model-t] What are we trying to protect

[Christian Huitema <[e-mail]>]

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

> On Sun, Aug 4, 2019 at 12:14 AM Dominique Lazanski
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>
>
>     On 4 Aug 2019, at 06:08, Eric Rescorla <[e-mail]
>     <mailto:[e-mail]>> 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?
>
>
> 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.

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