Re: [Model-t] What are we trying to protect

Bret Jordan <jordan.ietf@gmail.com> Mon, 05 August 2019 14:07 UTC

Return-Path: <jordan.ietf@gmail.com>
X-Original-To: model-t@ietfa.amsl.com
Delivered-To: model-t@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4D71201EC for <model-t@ietfa.amsl.com>; Mon, 5 Aug 2019 07:07:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 iMkIJQLajPDL for <model-t@ietfa.amsl.com>; Mon, 5 Aug 2019 07:07:49 -0700 (PDT)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 358CA12018A for <model-t@iab.org>; Mon, 5 Aug 2019 07:07:49 -0700 (PDT)
Received: by mail-pl1-x636.google.com with SMTP id y8so36539688plr.12 for <model-t@iab.org>; Mon, 05 Aug 2019 07:07:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=imoYpn+ZiEGfOLUX1BYhU4lxWPPelLuc6+yk5gjzgZ4=; b=M8IH1WI7oKvjdmstwLNXJFH2KblilKmknxhlDRhfcGie1Qax3EjeoeGZv1qvfkSYIT 6Ewqx+x25BzaPj13xsiE7VN75eBvVpKO1wPTf31zIe9bguk2HlZwzZEJkl/U1QQP24lr j9V26os+tAOyRNAlGQMxT4XJohzmTanpKA/RdkIMwYOp6tzdh2uoQk886kLtTp/664+A IvxiXZTGfLErRrs9P4JDk3C9cqLRCEqYcCAM5QsU2yhb+wksxqYSuuUmzWdL5hRu+LTA fOod5oQX8AbVi+khQIycEaEbyIyfmlj/dj2I37ieGpVlUN2T6Dw/dwNX9uEYIvYKMu6M IrMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=imoYpn+ZiEGfOLUX1BYhU4lxWPPelLuc6+yk5gjzgZ4=; b=fw/CJrHHJ4gwjQW8W67ISYRNayugdvDOvEAFWtGghSyuV12FJsXvbBFz1XrdCMZZcd T3GAdDTgj+Kftxy2cEH4BhL01PWyIKYN25seSm7ygm1OkmQC/bUnvNpsQj/x4RpXBmsy 03Ur/9qoHCeJir4+Yu0HLUgwEw97cD59Q93SQoTbm/H10+0AIwtFNnTQSYHCI2BE7FB7 vFbaC4oFX6VZ6h3NdGkONxrR8e7nkmTUBFERUHi3sRG1nlYjkBM3zZAsyKhQf6adsUdS +mRzp7MdNZG15kB9jrpw0xF+XvDCgVVltx/VGEHNsUOoG0/Vp/TOka4snWdJKC6qDXmE zN0A==
X-Gm-Message-State: APjAAAUrhgBP8D6M9W6p1uMQgoZtGAuBQ31xBOJTRpRaU1nEoYUI/iOz lzJivUkXc740RGNX3FFX9oU=
X-Google-Smtp-Source: APXvYqyJIaUd9uwQ1dp46m65Xl1Q03eoJ7v51+0PrhTJM7ZtUQNL8ghZf1ginLi/a2WS+PQGMykyCg==
X-Received: by 2002:a17:902:20b:: with SMTP id 11mr146517352plc.78.1565014068767; Mon, 05 Aug 2019 07:07:48 -0700 (PDT)
Received: from [10.128.64.149] ([136.60.227.81]) by smtp.gmail.com with ESMTPSA id l26sm96944402pgb.90.2019.08.05.07.07.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Aug 2019 07:07:48 -0700 (PDT)
From: Bret Jordan <jordan.ietf@gmail.com>
Message-Id: <DA015630-9751-423F-A6D9-CEB01B4E6612@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_448F04D9-ACEF-4A2A-86AE-10E6EBA1B813"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 05 Aug 2019 08:07:46 -0600
In-Reply-To: <ADAEE6C9-4974-4955-95E6-603B9A857BF9@fugue.com>
Cc: Christian Huitema <huitema@huitema.net>, Eric Rescorla <ekr@rtfm.com>, Dominique Lazanski <dml@lastpresslabel.com>, model-t@iab.org
To: Ted Lemon <mellon@fugue.com>
References: <c3a112ba-baab-1cb0-97ad-21ff9999a637@cs.tcd.ie> <29756028-95f1-e6e5-b3ea-562cbc635df0@sandelman.ca> <5ef15ad2-5b20-e871-0d01-17cf906051c1@cs.tcd.ie> <22633.1564768705@localhost> <e7c02d44-353f-406c-818e-06a2e49ee212@www.fastmail.com> <5879878A-7CEA-4030-BB72-108CC4122719@gmail.com> <d253231a-d35d-e7c9-e3ae-5c7d7915566e@bluepopcorn.net> <06F0AE14-4413-4022-A804-C1B58E2702CE@fugue.com> <52BAC141-CB25-4072-B556-6325912F1ADD@gmail.com> <9a1555ca-6699-75f1-683e-2a3a2a539a11@cs.tcd.ie> <fbb6866d-87af-abea-42b4-8bb45959ea6a@huitema.net> <A8ABBBFF-9967-4F3B-974F-2DC5953D5DD9@gmail.com> <CABcZeBOKnaa7t3Nc=uq4sB2OQ+uKp=+_LHqX3bBBmpy3RY3dCA@mail.gmail.com> <86157132-D401-4033-A72B-AD4859DB6696@lastpresslabel.com> <CABcZeBPBy+6W-Yg4vMF1aCyNkE7XAJ81HaM75hKa--gRnpUVbg@mail.gmail.com> <f8782dce-970a-fb11-372b-bc122878308b@huitema.net> <ADAEE6C9-4974-4955-95E6-603B9A857BF9@fugue.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/model-t/OJUbTNXwqyruVBuBkwMExR1pmsY>
Subject: Re: [Model-t] What are we trying to protect
X-BeenThere: model-t@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model <model-t.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/model-t>, <mailto:model-t-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/model-t/>
List-Post: <mailto:model-t@iab.org>
List-Help: <mailto:model-t-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/model-t>, <mailto:model-t-request@iab.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Aug 2019 14:07:51 -0000

I agree with you Ted, this is something we need.  We just need to work through the details to help make sure everyone understands this problem.  We also need to figure out a way to document this material in a way that everyone can understand, but does not cut the information off at the knees.  Too often I feel like we have historically narrowed this information down to statisfy our own confirmation bias. 

I fully get that many here do not understand the attack lifecycle at the same level or understand what an intrusion set is and how that relates to threat actor techniques, tactics, and procedures (or their modus operandi). I also know that most here probably do not track threat actor activity.  But some of us do.  We need to bring some of this knowledge and expertise in to the IETF to help insure that we design things that improve overall security for end users on the internet.

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 Aug 5, 2019, at 7:50 AM, Ted Lemon <mellon@fugue.com> wrote:
> 
> I think this is a great approach, Christian.   If we follow your model we should be able to start from what we know and avoid boiling the ocean, without inappropriately skipping some modeling that we actually need to do because it borders on our space, even though it is not itself our space.
> 
> There are a few other things I think we should do.
> 
> First, you may have noticed that I don’t actually show a clear understanding of what the goals of this effort are in my comments.   This is because I’m a security area consumer more than a security area producer, so I wasn’t in the saag meeting.  I saw Stephen’s mail go by about “security models” and thought to myself “excellent, we need that.”   That’s literally all I know about what the plan is for this discussion.   It would be good to actually write down what our goals are.
> 
> Second, I don’t think we all agree on how we want to describe threat models.   If there is to be an abbreviated form for describing threats (as opposed to natural English) we need to document what that form is in sufficient detail that IETF participants who are not SMEs can understand it, and hopefully even contribute.   I’m not saying we have to write an RFC, but at a minimum there should be a wiki that has the needed information.
> 
> I also don’t think we even agree on what we mean by threat models.   Of course we mean models of threats, but at what level of detail?   How close to the code are these models?  How general, or how specific?   This may all be obvious to people on this list who are SMEs, but I’m not, so for me it would help to describe what we mean by “threat model,” not because anybody here is unclear on the basic concept, but because I suspect we don’t agree on the particulars.
> 
> As an example, the models that Bret has described don’t seem as if they would be helpful to me.  This doesn’t mean that they aren’t right—it either means that I don’t understand them clearly, or that we simply have different requirements.   It may be that what I want is not what should be produced here—I’m not claiming otherwise.   But it would be good to get some clarity on that.
>