Re: [Model-t] Fwd: New Version Notification for draft-arkko-farrell-arch-model-t-redux-00.txt

[Martin Thomson <[e-mail]>]

So this is something of a grab-bag for me, and while I like most of the principles you lay out (especially the ones I gave you :), I'm having a bit of a problem with the level at which this is aimed.

It might even make sense to up-level this and talk about this in terms of systems design.  I took a small step in this direction with -tmi, at the same time trying to keep it grounded in something that has a practical application to protocol design.  In contrast, this seems like this is a grander attempt at documenting systems design principles.

What I see here is several different iterations on the basic idea that system X is a complex system with multiple pieces and varying levels of exposure to different threats.  For instance, the computer you use is massively complex and has to contend with vulnerabilities at multiple levels.  Different components are also produced and maintained (to varying degrees) by different entities with their own independent interests that are sometimes in tension.  The same goes for use of online services of various sorts.

For communications security design, it still remains a useful simplification to treat endpoints as faithfully representing their own interests.  For systems design, this makes no sense at all.  At the system level the principle of least privilege applies.  That's a dramatic change in posture.

Indeed, if I was feeling even a little reductionist, I could say that Section 3 could be replaced in its entirely with "Apply the principle of least privilege".

Separately, I think that this third point isn't just about tracking, it's the nature of information that once release it is hard/impossible to know what is done with that information.

But I think that there is something in here that the IETF might agree to.  In the same way that RFC 8890 articulates an aspiration to adopt a particular stance regarding rights of different constituencies in design, this might introduce some notion that different systems designs are more worthy than others.  That is, we might favour protocols that are produced in support of systems that align with these principles over those that do not.

I'm not sure that this document is in a form where I can see it being useful toward that end just yet.  But there's a glimmer in there.  And that is very much not the evolution of the Internet threat model that was originally envisaged or that this claims might be needed.

Separately, what happened to the work from Chris and Ekr regarding evolution of the design space?  I see no evidence of that input here.  Is that because you believe that to be orthogonal work or something else?

Hope that is useful input,
Martin

On Tue, Nov 3, 2020, at 18:56, Jari Arkko wrote:
> We’ve had discussions about what kinds of documents are reasonable 
> outputs from this group. So far we’ve had kind of a kitchen sink 
> approach, for instance Stephen’s and my earlier document contained a 
> ton of material, e.g., about all possible attacks we could think of, 
> all the guidance we thought could be made, and so on.
> 
> As discussed previously it may make sense to narrow this down a bit. 
> Obviously there’s plenty of work left, but we submitted a very drafty 
> initial document that attempts to list the primary categories of 
> attacks, and discusses architectural principles in  four areas:
> 
>    o  Security of devices, including the user's own devices.
> 
>    o  Security of data at rest, in various parts of the system.
> 
>    o  Tracking and identification of users and their devices.
> 
>    o  Role of intermediaries, and in particular information passing 
> through them.
> 
> The description of the attacks, and some of the principles follows what 
> we’ve had in previous documents, but we’re trying to focus on what the 
> important bits are.
> 
> Comments appreciated.
> 
> Jari
> 
> > Begin forwarded message:
> > 
> > *From: *[e-mail]
> > *Subject: **New Version Notification for draft-arkko-farrell-arch-model-t-redux-00.txt*
> > *Date: *3 November 2020 at 1.39.46 GMT+2
> > *To: *"Jari Arkko" <[e-mail]>, "Stephen Farrell" <[e-mail]>
> > 
> > 
> > A new version of I-D, draft-arkko-farrell-arch-model-t-redux-00.txt
> > has been successfully submitted by Jari Arkko and posted to the
> > IETF repository.
> > 
> > Name: draft-arkko-farrell-arch-model-t-redux
> > Revision: 00
> > Title: Internet Threat Model Evolution: Background and Principles
> > Document date: 2020-11-03
> > Group: Individual Submission
> > Pages: 26
> > URL:            https://www.ietf.org/archive/id/draft-arkko-farrell-arch-model-t-redux-00.txt
> > Status:         https://datatracker.ietf.org/doc/draft-arkko-farrell-arch-model-t-redux/
> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-arkko-farrell-arch-model-t-redux
> > Htmlized:       https://tools.ietf.org/html/draft-arkko-farrell-arch-model-t-redux-00
> > 
> > 
> > Abstract:
> >   Communications security has been at the center of many security
> >   improvements in the Internet.  The goal has been to ensure that
> >   communications are protected against outside observers and attackers.
> > 
> >   This memo suggests that the existing RFC 3552 threat model, while
> >   important and still valid, is no longer alone sufficient to cater for
> >   the pressing security and privacy issues seen on the Internet today.
> >   For instance, it is often also necessary to protect against endpoints
> >   that are compromised, malicious, or whose interests simply do not
> >   align with the interests of users.  While such protection is
> >   difficult, there are some measures that can be taken and we argue
> >   that investigation of these issues is warranted.
> > 
> >   It is particularly important to ensure that as we continue to develop
> >   Internet technology, non-communications security related threats, and
> >   privacy issues, are properly understood.
> > 
> > 
> > 
> > 
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> > 
> > The IETF Secretariat
> > 
> > 
> 
> -- 
> Model-t mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/model-t
>