Re: [Smart] [Secdispatch] New Version Notification for draft-lazanski-smart-users-internet-00.txt

[Eric Rescorla <[e-mail]>]

I more or less agree with Stephen's position.

First, I recognize that this focus on secure endpoints talking to each
other is probably the part of 3552 that people are most unhappy
about. As I was almost certainly the person who wrote that text, it might
be helpful if I laid out some background.

First, RFC 3552 isn't intended to say that endpoint threats aren't
real, but merely that they are out of scope because they are hard
to address. Here's the text in context:

   The Internet environment has a fairly well understood threat model.
   In general, we assume that the end-systems engaging in a protocol
   exchange have not themselves been compromised.  Protecting against an
   attack when one of the end-systems has been compromised is
   extraordinarily difficult.  It is, however, possible to design
   protocols which minimize the extent of the damage done under these
   circumstances.

For a more narrow statement with a similar theme (but extended to
the Web platform, see
https://www.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model-
and
https://www.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t-compromised-infected-machines-in-Chrome-s-threat-model-
):

   This is essentially the same situation as with physically-local
   attacks. The attacker's code, when it runs as your user account on
   your machine, can do anything you can do. (See also Microsoft's Ten
   Immutable Laws Of Security.)

However, RFC 3552 is primarily oriented towards what can be
standardized and in particular towards protocols, and generally secure
protocols require some sort of TCB to be effective. Obviously, as
alluded to in 3552, to the extent to which protocols can be designed
to minimize damage, and we routinely attempt to do so. Examples of
this include the use of Forward Secure algorithms and trying to avoid
or mitigate designs with single points of failure (as with Certificate
Transparency).  I know that PHB has some ideas along these lines; I
haven't studied them enough to know what I think, but that sort of
thing is generally in scope as well.

This to some extent goes to Section 2 of draft-lazanski. I certainly
agree that to the extent to which it is possible to design
cryptographic solutions to prevent data breaches, it is useful to do
so, and protocols for doing that would potentially be in scope for
IETF. I say "potentially" because I'm not sure that (a) standards are
necessary in this space beyond the kind of work we are already doing
or (b) that we would have the community to define them, but I don't
see an in principle barrier [0] I certainly would not expect 3552 to
be deployed to preclude that kind of work.

Similarly, I don't think that the kinds of botnet attacks described
in Section 3 are out of scope for 3552, though I see how it could
be read this way. However I think that the idea of a malicious
counterparty is clearly in scope if we assume that the attacker
controls the network. Here too, I wouldn't expect 3552 to be deployed
to preclude that kind of work; we have done plenty of anti-DoS work
in IETF (whether it is good enough is a different story).


Turning now to the document itself, its language seems to be trying
to stake out a very strong position, but I'm not quite sure what that
position is. For instance:

   themselves. These assumptions have led to a focus on communications
   security and the development of protocols that place this kind of
   security above all else. Ironically - or coincidentally - as the
   development of these protocols have taken place over the last
   several decades, there has been and continues to be a sharp rise in
   cyber attacks. The Internet threat model in RFC 3552 does not even
   mention that the greatest threat to the Internet is the growing
   scale and variety of cyber attacks against all types of endpoints
   that is resulting in significant data breaches. This now needs to
   change.

First, I'm not sure that I agree that cyber attacks on endpoints are
the greatest threat to the Internet, but even assuming that's so,
what are the implications of that for work in the IETF? It's one thing
to change the words of 3552, but what work specifically would we
do if those words were different.

Second, I think it's quite likely true that the IETF has focused
on communications security, and this document seems to be trying
to argue that that's to the detriment of other kinds of security,
both here and in other places:

   Internet security research and technical development must accept the
   reality of all the security issues in the Internet ecosystem.
   Decisions being made in the name of privacy are sometimes leading to
   larger inadvertent security and privacy losses.

I'd like to try to explore this argument a bit. Specifically, it might
be the case that the IETF has just ignored non-comsec and that if we
had spent more time on it, that would be better. Alternatively, it
could be true that the IETF's focus on comsec has actively harmed
other kinds of security. One gets the sense that this document wants
to argue the latter point, but it doesn't really come out and say it,
let alone substantiate it. That, rather than arguing about the completeness
or appropriateness of RFC 3552, might be a better place to start.

-Ekr


[0] Indeed, work like token binding is arguably a stab at some of this
stuff.

On Sun, Jul 14, 2019 at 3:26 AM Stephen Farrell <[e-mail]>
wrote:

>
> Hiya,
>
> On 14/07/2019 03:06, Kathleen Moriarty wrote:
> > It's a good start toward broadening
> > the conversation on the Internet threat model and I do agree that is
> > necessary.
>
> FWIW, I don't agree that this is a good start.
>
> ISTM that this draft is far too opinionated, for example
> claiming that "IETF attendees are privacy-focused", (how
> does the author know?), claiming it "unthinkable" that
> something isn't done, and that "Internet security research
> and technical development must accept the reality of all
> the security issues in the Internet ecosystem" (though
> I'm not sure I can parse that last quote at all).
>
> Towards the end we get: "Endpoints have changed over the
> last 10 years, but assumptions about endpoints in the IETF
> hasn't changed in that time" - I don't know how the
> author knows what assumptions may or may not be made
> by IETF participants (not "attendees" of course).
>
> And perhaps most oddly, this bold assertion: "Further, it
> is imperative that new conclusions and recommendations
> from a revisited threat model are backed up by research, case
> studies and experience - rather than bold assertions." ;-)
>
> The list of breaches and botnets is fine, but not much
> use without any analysis of how those happened. We need a
> good bit more work to figure out whether any changes to
> protocols or protocol design are actually warranted or
> useful in the face of these kinds of incident. (Hence
> the oddity of the bold assertion above.)
>
> Lastly, ISTM important, if any discussion here is to
> be worthwhile, to recognise from the start that existing
> IETF consensus positions in this space are not likely to
> be discarded - those were arrived at after a lot iterations
> of a lot of debate by well-informed IETF participants.
> (Despite what some may claim;-) So I reckon the right
> discussion to have is about how to extend and not discard
> the 3552 threat model. Any other attempted changes would
> seem to me to require a shift in deployments from 2-party
> to multi-party protocols, which is unrealistic, or to
> require magical trust in middleboxes, which would be plain
> silly and seems highly unlikely to be something for which
> IETF consensus would be established.
>
> > Also - is this a request to present at SecDispatch?
>
> I hope not. This draft is IMO clearly not ready for that.
> An initial discussion about threat models and how to
> approach this kind of work at saag may be worthwhile (and
> I think Jari has asked the sec ADs for such a slot).
>
> Cheers,
> S.
> _______________________________________________
> Secdispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdispatch
>