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

[Stephen Farrell <[e-mail]>]

Hiya,

On 23/09/2019 18:45, Christian Huitema wrote:
> 
> 
>> On Sep 23, 2019, at 5:32 AM, Stephen Farrell
>> <[e-mail]> wrote:
>> 
>> 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.
> 
> 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?

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.

> 
> -- Christian Huitema
>