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

[Watson Ladd <[e-mail]>]

On Mon, Sep 23, 2019, 1:47 PM Bret Jordan <[e-mail]> 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.


> 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 23, 2019, at 1:52 PM, Christian Huitema <[e-mail]>
> wrote:
>
>
> On 9/23/2019 9:26 AM, Watson Ladd wrote:
>
>
>
> On Mon, Sep 23, 2019, 11:07 AM Joel M. Halpern <[e-mail]>
> wrote:
>
>> 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.
>>
>
> 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.
>
>
> 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
> [e-mail]
> https://www.iab.org/mailman/listinfo/model-t
>
>
> --
> Model-t mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/model-t
>