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

[Mark O <[e-mail]>]

Thanks, Dominique, for bringing this draft to the list. It's not a complete survey of all the threats facing users and systems on the Internet but it does highlight some omissions from the current threat model.



I attended the tutorial session on how to write security considerations on 20 July. Something I heard Yoav say was that the IETF mostly focuses on ComSec issues, and as a result there's not usually any discussion in the security considerations of how to protect the host so that private information doesn't leak out; also that the security considerations all too often ignore operational considerations. This reflects what I have seen in Internet drafts but does seem to be ignoring a class of attacks that arguably ought to be in scope.



Checking RFC 3552 to see what's actually in scope for the security considerations, it says (Section 2: The Goals of Security):



   We can loosely divide security goals into those related to protecting

   communications (COMMUNICATION SECURITY, also known as COMSEC) and

   those relating to protecting systems (ADMINISTRATIVE SECURITY or

   SYSTEM SECURITY).  Since communications are carried out by systems

   and access to systems is through communications channels, these goals

   obviously interlock, but they can also be independently provided.



So System Security and the protection of systems is apparently in scope. Section 3 specifies the Internet threat model - and we can classify the attacks here according to whether they are Communications Security or System Security:



3.2.1 Confidentiality violation - COMSEC

3.2.2 Password sniffing - COMSEC

3.2.3 Offline cryptographic attacks - COMSEC (capturing challenge-response); SYSTEM SECURITY (stealing password file)

3.3.1 Replay attacks - COMSEC

3.3.2 Message insertion - COMSEC

3.3.3 Message deletion - COMSEC

3.3.4 Message modification - COMSEC

3.3.5 Man-in-the-middle - COMSEC

3.5 On-path versus off-path - COMSEC

3.6 Link-local - COMSEC



Then Section 5 describes the mandatory components of the security considerations:



   Authors MUST describe



      1.   which attacks are out of scope (and why!)

      2.   which attacks are in-scope

      2.1  and the protocol is susceptible to

      2.2  and the protocol protects against



   At least the following forms of attack MUST be considered:

   eavesdropping, replay, message insertion, deletion, modification, and

   man-in-the-middle.  Potential denial of service attacks MUST be

   identified as well.



So although System Security is recognised as a security goal, there's no specific guidance on what the threats to System Security are and no requirement for them to be addressed in the security considerations section. This may have contributed towards protocol design concentrating more on ComSec than on other aspects of System security. The security considerations section should at least call out the threats that result from the compromise of endpoints, even if no mitigation is possible.



I note that Jari Arkko's draft-arkko-arch-internet-threat-model-01 has been updated and that this makes similar points regarding the need to address security threats other than ComSec. I support the additions to the text of the draft, including this one:



   7.  Treat parties that your equipment connects to with suspicion,

       even if the communications are encrypted.  The other endpoint may

       misuse any information or control opportunity in the

       communication.  Similarly, even parties within your own system

       need to be treated with suspicision, as some nodes may become

       compromised.



I also welcome that Stephen Farrell's draft-farrell-etm-03 recognises additional categories of attacks including supply chain attacks and leaky buckets, as well as the kinds of breaches detailed in Dominique's draft. I do think however that Stephen's suggested change to the wording of RFC 3552:



   OLD: In general, we assume that the end-systems engaging in a

   protocol exchange have not themselves been compromised.



   NEW:



   In general, we assume that one of the protocol engines engaging in a

   protocol exchange has not been compromised at the run-time of the

   exchange.



is restrictive. We use PFS to protect systems against compromises of the endpoint _after_ the protocol exchange has taken place.



The Lazanski, Arkko and Farrell drafts could all make valuable contributions towards an improved Internet threat model.



In response to Eric:

  *   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.



I agree. Research into the effects that the focus on ComSec has had on other forms of security has not been brought to the IETF in a systematic way.



-- Mark









From: Smart <[e-mail]>On Behalf Of Eric Rescorla
Sent: 14 July 2019 17:24
To: Stephen Farrell <[e-mail]>
Cc: [e-mail]; Kathleen Moriarty <[e-mail]>; Dominique Lazanski <[e-mail]>; IETF SecDispatch <[e-mail]>
Subject: Re: [Smart] [Secdispatch] New Version Notification for draft-lazanski-smart-users-internet-00.txt



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

This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [e-mail]. All material is UK Crown Copyright (c)