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

Dominique Lazanski <dml@lastpresslabel.com> Sun, 04 August 2019 16:12 UTC

Return-Path: <dml@lastpresslabel.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 EB6E8120033 for <model-t@ietfa.amsl.com>; Sun, 4 Aug 2019 09:12:52 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lastpresslabel-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 GluXfzz9cBz0 for <model-t@ietfa.amsl.com>; Sun, 4 Aug 2019 09:12:50 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 BB38D120025 for <model-t@iab.org>; Sun, 4 Aug 2019 09:12:49 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id s3so72501453wms.2 for <model-t@iab.org>; Sun, 04 Aug 2019 09:12:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lastpresslabel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eQ94azV1RuuyfFQhzaL3RXlqpkVMwLLA6RTQYAvuYok=; b=WWDrMT1utx5eVcdIBpME9rznTm5o8uCLeAh3bIYC7qJGbmZVnjS/MpIXqJXRjXHTvJ WqBEZR7L4L0UFqZyG1ImnPWu7IOiGuKSH7tPU6uWuvR6TOn1514B8UxjQ9C/8ykoZhvt xggE/iMmDaDMqKNNbkklGhlbimSR7XP28x7UH+OX87Av2ocDpfJtif+yqub7J1UsvzBY oHMVN4dVmFu9kEFAF4vUsbARu05uQkei9bTPBD35u1y6pJK2EZgJYC1FQbsO0b39Zzn+ i7oVGu6bboAkwxv6uCIzWPktFcUm0HjqIsUz+KH2RPoOlRr9zkZ87Gb+rrFUngh7EcIN 39rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eQ94azV1RuuyfFQhzaL3RXlqpkVMwLLA6RTQYAvuYok=; b=KaQfZPbzGBVnTlaCQaQ9y2pzC7zFNIoCjk4BkD42y/3vV6TVsHbyCrRtGLW+/wbhFD 68hdYmYEk5pKKPrm4D7YXAVxL/YuaDwb96ZsHoCQbPs3g/uCZZbpv6p899IX2sghbtVd bEsFPvK3rSrxMAjzMr/prl0WeG4UC9mehAq/SCtCFcyaXsQ028BCjB8bn5ovUxDPJPYH K/8IZ+saqInpPROauEI7J5WhL5LT4oAyG4819AFoG+W2iloQL8gHxqI8Mw1qrRmMpDkj jg7jK9XfidrZ96l3q1oTpX5f1oN6BV0H6/9LtW6lfsIxWpzGBQjuv6thvelObGn29WEA c7BQ==
X-Gm-Message-State: APjAAAW0C6/P/wyLO+iaYb9zIhIB9+r3Szm5+6p5tHMf8Nr5FqobR9+g 8aKxdYaaXqAeudXozhifYU7I/n+defo=
X-Google-Smtp-Source: APXvYqz/znKl8tgbQ9xjAghySc0WCYMxWfocQD6zqRJmkCNO11dAZQSEcxohP3Yxd6vmxFUvYvdW0Q==
X-Received: by 2002:a1c:e341:: with SMTP id a62mr14750871wmh.165.1564935167916; Sun, 04 Aug 2019 09:12:47 -0700 (PDT)
Received: from [10.235.3.192] ([85.255.234.86]) by smtp.gmail.com with ESMTPSA id h16sm94127157wrv.88.2019.08.04.09.12.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Aug 2019 09:12:47 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-F5ECD853-EEA8-423E-9294-89E82FBAD6A3"
Mime-Version: 1.0 (1.0)
From: Dominique Lazanski <dml@lastpresslabel.com>
X-Mailer: iPhone Mail (16F203)
In-Reply-To: <ADF23214-F1A8-4996-A56D-3DB037D81EA9@fugue.com>
Date: Sun, 04 Aug 2019 17:12:45 +0100
Cc: Watson Ladd <watsonbladd@gmail.com>, Bret Jordan <jordan.ietf@gmail.com>, Eric Rescorla <ekr@rtfm.com>, Christian Huitema <huitema@huitema.net>, model-t@iab.org
Content-Transfer-Encoding: 7bit
Message-Id: <25D36609-FD10-4DF7-8142-6F183A3EBD16@lastpresslabel.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> <5281A343-35C0-4F4D-949D-02C46FA07801@lastpresslabel.com> <86639B71-F616-48CC-96AB-719F7168F087@gmail.com> <CACsn0cktsrVnzVByV9NzcE4jDpMdJ1UBPzut5PTzVSesMXXaNg@mail.gmail.com> <ADF23214-F1A8-4996-A56D-3DB037D81EA9@fugue.com>
To: Ted Lemon <mellon@fugue.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/model-t/hXqLlu11K6rAsuqjrBUkBF760aA>
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: Sun, 04 Aug 2019 16:12:53 -0000

I agree with Ted and Brett. 

Worse case scenario is that we document too much and decide later that we are going to narrow the scope. But to start let’s include everything. 

-dml

> On 4 Aug 2019, at 17:00, Ted Lemon <mellon@fugue.com> wrote:
> 
> If the point of this effort is to document threat models, then we aren’t writing protocols at least here. It’s probably useful if the threat models we produce describe things we don’t built, because they interact with things we do build. 
> 
> Sent from my iPhone
> 
>> On Aug 4, 2019, at 10:53 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
>> 
>> But we design protocol, we don't design clients. Ultimately any
>> product has to be useful for the IETF, and should result in changes to
>> how people think.
>> 
>> Efforts to end the use of bearer tokens, forward secrecy, etc. are
>> very much motivated by a model where a client system can be
>> compromised. I don't think that model is unknown, although perhaps it
>> should be added explicitly.
>> 
>> I can definitely think of issues that are "endpoint" issues where
>> protocols have fallen short (my Amazon and Johnny examples) due to the
>> mismatch between the Internet and Unix, and these are threats that
>> generally have fallen out of scope. (NFS permissions issues are
>> another example of this)
>> 
>>> On Sun, Aug 4, 2019 at 8:40 AM Bret Jordan <jordan.ietf@gmail.com> wrote:
>>> 
>>> I agree here with Dominique.
>>> 
>>> More specifically, we need to understand that types of attacks that impact clients and how those attacks take advantage of the overall weakness of clients. Doing this will help us better design protocols.  We need to stop saying that clients are secure or even worse, kicking the can down the road and not worrying about it.
>>> 
>>> In a previous email I called out 4 high level types of attacks that impact users data, users privacy, and the overall integrity of endpoints.
>>> 
>>> 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 4, 2019, at 3:49 AM, Dominique Lazanski <dml@lastpresslabel.com> wrote:
>>> 
>>> 
>>> 
>>> On 4 Aug 2019, at 10:09, Eric Rescorla <ekr@rtfm.com> wrote:
>>> 
>>> 
>>> 
>>>> On Sun, Aug 4, 2019 at 12:14 AM Dominique Lazanski <dml@lastpresslabel.com> wrote:
>>>> 
>>>> 
>>>> 
>>>> On 4 Aug 2019, at 06:08, Eric Rescorla <ekr@rtfm.com> wrote:
>>>> 
>>>> his seems like a reasonable problem statement for the overall problem of computer security, but not really for IETF.
>>>> 
>>>> 
>>>> But computer security is Internet security. It is rare that ‘things’ are not connected to the Internet  (with the exception of intranets however the same type of devices are connected to both).
>>>> 
>>>> If some attacks are initiated at the pint of ‘things’ in order to compromise the Internet I don’t see why this shouldn’t be in scope?
>>> 
>>> 
>>> Well, I didn't say anything about "things" one way or the other.
>>> 
>>> However, my point is that while compromise of endpoints necessarily negatively affects the Internet, actually protecting those endpoints against compromise is outside the scope of the IETF. That's not to say it's not important, it's just not IETF work. To provide two examples perhaps closer to home:
>>> 
>>> 
>>> I disagree. Any issue that impacts the Internet should be considered.
>>> 
>>> 
>>> - Even though compromise of the Web is bad for the Internet, the IETF has largely punted the security of the Web itself to W3C and WHATWG.
>>> 
>>> 
>>> Times are changing!
>>> 
>>> - Compromise of the WebPKI would obviously be very bad for many protocols the IETF has designed, but the management of the WebPKI is done by CABF, not IETF.
>>> 
>>> 
>>> But that’s the whole point of this group and discussion is to think about all the issues and the changes and the wider problems that are happening. I’d rather look at everything and narrow the scope of and when necessary. All three Internet drafts on this subject so far even acknowledge that.
>>> 
>>> 
>>> 
>>> -Ekr
>>> 
>>> -dml
>>> 
>>> 
>>>> 
>>>> FWIW I think Christian and Bret’s emails outline issues that should be included in scope.
>>>> 
>>>> To take a concrete example memory reading attacks like Spectre are a threat to user data and something that browser vendors spend a fair amount of energy working on, but they're mostly not in scope for IETF [0]. There's nothing wrong with that, it's just division of labor.
>>>> 
>>>> -Ekr
>>>> 
>>>> [0] I say "mostly" because (a) we need to take the security implications of these kinds of attacks in our protocol designs and (b) there might be some small pieces of IETF work like CORB, though that seems to be mostly being done elsewhere.
>>>> 
>>>>> On Sat, Aug 3, 2019 at 2:47 PM Bret Jordan <jordan.ietf@gmail.com> wrote:
>>>>> 
>>>>> Protection of end users’ data
>>>>> 
>>>>> Protection of an organization’s data
>>>>> 
>>>>> Protection of devices owned by an end user or an organization
>>>>> 
>>>>> Protection of network equipment
>>>>> 
>>>>> Protection of SCADA system
>>>>> 
>>>>> Protection of critical infrastructure
>>>>> 
>>>>> Protection of IoT and soon to be released 5G devices
>>>>> 
>>>>> Protection of cost optimized controllers
>>>>> 
>>>>> 
>>>>> The problem we have had in the past is we want to call this one of the following, but each one does not encompass the full picture.
>>>>> 1) Computer security
>>>>> 2) Data security
>>>>> 3) Information security
>>>>> 4) Communication security
>>>>> 5) Network security
>>>>> 6) Application security
>>>>> Etc, etc,
>>>>> 
>>>>> So if you way we are just dealing with communication security or information security we are missing a significant piece of the pie.
>>>>> 
>>>>> 
>>>>> 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."
>>>>> 
>>>>> 
>>>>> Reading this thread, I think that we are missing a step. We cannot
>>>>> define attacks without defining first the assets that need to be
>>>>> protected.. Different actors probably have different views on that, such as:
>>>>> 
>>>>> 1) Continuous operation of the Internet
>>>>> 
>>>>> 2) Continuous operation of a specific Internet provider
>>>>> 
>>>>> 3) Continuous availability of an Internet Service
>>>>> 
>>>>> 4) Continuous connectivity for a given user
>>>>> 
>>>>> 5) Protection of databases used by services and enterprises
>>>>> 
>>>>> 6) Protection of the personal data of users
>>>>> 
>>>>> Do we have agreement on what we are trying to protect?
>>>>> 
>>>>> -- Christian Huitema
>>>>> 
>>>>> 
>>>>> --
>>>>> Model-t mailing list
>>>>> Model-t@iab.org
>>>>> https://www.iab.org/mailman/listinfo/model-t
>>>>> 
>>>>> 
>>>>> --
>>>>> Model-t mailing list
>>>>> Model-t@iab.org
>>>>> https://www.iab.org/mailman/listinfo/model-t
>>>> 
>>>> --
>>>> Model-t mailing list
>>>> Model-t@iab.org
>>>> https://www.iab.org/mailman/listinfo/model-t
>>> 
>>> 
>>> --
>>> Model-t mailing list
>>> Model-t@iab.org
>>> https://www.iab.org/mailman/listinfo/model-t
>> 
>> 
>> 
>> -- 
>> "Man is born free, but everywhere he is in chains".
>> --Rousseau.
>> 
>> -- 
>> Model-t mailing list
>> Model-t@iab.org
>> https://www.iab.org/mailman/listinfo/model-t