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

Eric Rescorla <ekr@rtfm.com> Sun, 14 July 2019 21:25 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163C512019D for <secdispatch@ietfa.amsl.com>; Sun, 14 Jul 2019 14:25:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjhTGuUjBRbT for <secdispatch@ietfa.amsl.com>; Sun, 14 Jul 2019 14:25:09 -0700 (PDT)
Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ED5512018A for <Secdispatch@ietf.org>; Sun, 14 Jul 2019 14:25:09 -0700 (PDT)
Received: by mail-lf1-x144.google.com with SMTP id r15so4740658lfm.11 for <Secdispatch@ietf.org>; Sun, 14 Jul 2019 14:25:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kZKmDuhetClDFpNQG1TQYzFW2Cz/CZi/lJriCMh2NoU=; b=1aDAsNAikSmKmAlx5kX8NNkbXOcsWf50pkiQ0YGUqyaj18Vfc6loJ+ZRR5hOE0z4n1 KxpXGMeyJwh9Gd5ImgjcqitE25rs1LIMUcmiOOorbkkMfBIAombcmPpwxK6GHLtNfT5u wkyyi9V0sumJuxCEi2+lT+6EaE411oQFadnPvG7Pl7nlWRfjSWqaZvwfQCoLwoLBBTRD glq0TvroBdVmSPivWN1pdVbeJM7uoQ1YcKMhXUmf1Yk6bBc2aC2ZTVv6if2f2XaiN/jd bRtSEoY5tyinlDVBYMgx+tPHawTVNAsLN69kVl9SS6Q2aZRKrsVKhGnOBHuHYM3p3t3U 3esA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kZKmDuhetClDFpNQG1TQYzFW2Cz/CZi/lJriCMh2NoU=; b=ijqGWCszBR0wI7GTaA22l1bqNJTqlocRs0DxTD5p8Lh/6V2Wgv2/dc+jQ4BFwLp4Iz GlK7ih4/6qPRxCQJHXLoli2r6NkzVhbl9L1kY6uJKBq72YFRpsTPyvkzpqFvFOMVjpqw 0w6JeCJclz1DekV6eDUKotQymyZN0dEj+gm3DEAQVDhIARkNcPP3ELnZXvvtcQpw4k5C 3391bO8gu8gzq9i5MGaqKPCXokmk18HVGKAiGjnvUACGPohhzDk5xAMsRm59Q2J22DYS oRIIvXaWC2frTb6/AK5xSU/LqHqCb0i5EivpxFa7fUew071bBvj0r19py3G0IyzbeiyQ sNiw==
X-Gm-Message-State: APjAAAXGok+8CsmPkId+gsB1LbMA8bnqAb+SN8F7qBzO3kNI8xQYznSW dF18vtUZTAHJTqXEiVtA6dFb98KiMG/FkXwLndE=
X-Google-Smtp-Source: APXvYqxhMm2nAtb4Sce5QV4h6+rlnnMgOP06fQGPEUcojm/Xy/RqYYEW1OArLuCF/Bi5SMYIOsBmlc5MoOHEFoZaN9s=
X-Received: by 2002:a19:4a50:: with SMTP id x77mr9600237lfa.91.1563139507175; Sun, 14 Jul 2019 14:25:07 -0700 (PDT)
MIME-Version: 1.0
References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <CAMm+Lwh3KW6ZBbMktwmLcKyY8=_ysLYJF_7MsAuiOat6baQ=Kg@mail.gmail.com> <B551EF79-7E6E-4C4E-ADCA-6538F7972222@gmail.com> <CAMm+Lwg+2RFiXK43nJv7pD3OgM8y=ziVYxBkXD3F2kJyz37SxQ@mail.gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <CAHbuEH5WUv-a4nKt5YAZosO-vE773Jh3xn1+-hA=4J7RBERc3g@mail.gmail.com> <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie>
In-Reply-To: <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 14 Jul 2019 14:24:29 -0700
Message-ID: <CABcZeBNwmitpkJn0fCbNHOJtJ25yXdk6i6U9wK0a-9hwK1Tqcw@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, Dominique Lazanski <dml@lastpresslabel.com>, smart@irtf.org, IETF SecDispatch <Secdispatch@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000f55e1058daac7b7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/FlOuBXSyYRZpapszyTcR9k5fYjI>
Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Jul 2019 21:25:13 -0000

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 <stephen.farrell@cs.tcd.ie>
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
> Secdispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/secdispatch
>