Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Tue, 28 January 2020 14:36 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A6D1208F9 for <architecture-discuss@ietfa.amsl.com>; Tue, 28 Jan 2020 06:36:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 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, HK_SCAM=1.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 ARjtwpUCpiah for <architecture-discuss@ietfa.amsl.com>; Tue, 28 Jan 2020 06:36:22 -0800 (PST)
Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0: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 7C7301208B2 for <architecture-discuss@ietf.org>; Tue, 28 Jan 2020 06:36:21 -0800 (PST)
Received: by mail-ot1-x32c.google.com with SMTP id 66so12157625otd.9 for <architecture-discuss@ietf.org>; Tue, 28 Jan 2020 06:36:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QcEIZrHARenQsSkTQtm8ihAzX67XWsrmL73q1ifHG9Y=; b=nyyKYaTfRQ+GWUdb5pi++gFcoCn/imujy1j26YTr0GUf0sbQmA1MAD0Cu0YlTFm9jQ yUiWbEQA57bybjFX6iuAM6f0Gxto8bCud/JnYDbNP4ZTsHO1wBXOBzkEAhQaLgdb/Gmp jvXuktQbDwu40HznstWdU+3iW2EAWO1cP25Z6MIC2VbWr4FaVrvIAAysTUiLfUcMANeX FOKtftm2CuKt8wPBsHDPshEbnyj0sMvn2I5FVdulZODkitTwgUPC1jBLUTAbTom/AnVU GrDTMqas0NDAV28DFE2mD5KihxMEFRChbePhIewS4vcfhr8LA7vv69rf5gi2AqzTNk4w ODtQ==
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=QcEIZrHARenQsSkTQtm8ihAzX67XWsrmL73q1ifHG9Y=; b=GMnIFRGe8Vfu20GV7aNu4C6u4pxfhed84WQ67Nk2tSrfUWvmBTbnEvIw3n3KmQG8C1 aIhck+BDeiKFiMK+xPK0agoeALtkKi4wOyVXnZn2RVfBAbbhHDN3sNANuows+AteFi+C F8yrm0a+LVERK+JNQG9xsinZ/bio5juUOnc4czlWXjA7/lIm9FDAfgFSwaQ5FlAC6O/Z uwIbXDGzvKwYNTrqXNMk0b8ELR2mv3PCHtQoBETu+Q3E8aFSBePUspL3NLK6hh5s/6hJ 63jWhYlsy2fRL8lwZTChoBfnMJ5pROeBqJ5EQbSHQ4RDwCaZnS2AGXSWqMjoZK8d492r o6TQ==
X-Gm-Message-State: APjAAAWKrNK01kEUN42ohflCjnZmDmsAJzWsF9bFwKJKlHoKWDDHFhSp TCuCJ0LqBRcjqidv4nWM6SBnWDjps89UuvjF/GU=
X-Google-Smtp-Source: APXvYqwQ9u5GsnJpGZ2q7/Ad8NLtP2Xb8xSrcwqFjBGXINSccZ58Qg10RvIMqu/W+juimB7CEVEQVTNDpUaAY4dtOFs=
X-Received: by 2002:a9d:dc1:: with SMTP id 59mr16928287ots.250.1580222180791; Tue, 28 Jan 2020 06:36:20 -0800 (PST)
MIME-Version: 1.0
References: <E2D709DC-DD01-4946-B2F1-7EE0E101DEF0@piuha.net> <dff1c31e-44d4-6045-aaeb-03ac1e855200@gmail.com> <CABcZeBOYsP+SBNdLqc-wmyJAs1A+hvWbKud_XfvDgi9zJVMD+w@mail.gmail.com> <CA+9kkMDFm7nboqQY2OjNvmcWxs_30d_5NtBv8Nd1eLBnWKBaBw@mail.gmail.com> <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <C7FDAD8F-D66A-4618-9F87-B1BB9CEA191B@cisco.com> <CABcZeBPKFEEDqQEGXZAD87n5cCsA75+uMGp-brq0JXBoW91LjQ@mail.gmail.com> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <CACsn0ck9PDAOhZrbBZ7e4UVU7eNiSgrfVO7JL9zaYaX3if2WVw@mail.gmail.com> <DCE750AF-6439-4961-A4DA-ED855807F68E@cisco.com>
In-Reply-To: <DCE750AF-6439-4961-A4DA-ED855807F68E@cisco.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Tue, 28 Jan 2020 09:35:44 -0500
Message-ID: <CAHbuEH78SVseu5b0koqFBLQcoFKSFg0F6R30_4zTsGikSYCa2A@mail.gmail.com>
To: Eliot Lear <lear=40cisco.com@dmarc.ietf.org>
Cc: Watson Ladd <watsonbladd@gmail.com>, architecture-discuss@ietf.org, model-t@iab.org
Content-Type: multipart/alternative; boundary="000000000000c09d75059d3425af"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/bXxL8LGcp7BTDf6CkvbFC8Ktv1k>
Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2020 14:36:26 -0000

On Tue, Jan 28, 2020 at 1:44 AM Eliot Lear <lear=40cisco.com@dmarc.ietf.org>
wrote:

> Hi Watson,
>
> On 28 Jan 2020, at 02:35, Watson Ladd <watsonbladd@gmail.com> wrote:
>
>
>
> On Sun, Jan 26, 2020 at 1:44 AM Eliot Lear <lear@cisco.com> wrote:
>
>>   Let’s look at three specific examples that I’ve mentioned:
>>
>> 1.  Train signaling system needs to be audited both live and
>> retrospectively in the case of accidents.  This has to happen in such a way
>> that the auditor sees precisely what was sent by one endpoint and received
>> by the other.
>>
>> 2.  The case of “parent doesn’t want Internet toy to send video of
>> child”, when the camera is undisclosed (it’s an analog to the privacy
>> analysis on Alexa[1] and the now infamous NEST episode[2]).
>>
>> 3. CPAP machine or an AED/pace maker provide a control interface to the
>> doctor but the patient or his next of kin wants the data.
>>
>
> I've got a few more examples from real life:
>
> 4: We need to see who is sending pictures of Winnie the Pooh.
>
> 5: We don't want pictures of the inside of our detention centers to appear
> online.
>
> 6: I want to see everyone's credit card number at the coffee shop I run.
>
> Any discussion of tapping network communications because endpoints can't
> be trusted needs to take these cases seriously.
>
>
>
> Absolutely.  What I am suggesting is a relatively new twist on an old
> problem(*).  It’s important to understand the economic and policy aspects
> of how/whether to avoid [4] and [5], how to avoid [6] while at the same
> time addressing use cases I mentioned.
>
> So… today’s new information comes courtesy of the EFF.
>
>
> https://www.eff.org/deeplinks/2020/01/ring-doorbell-app-packed-third-party-trackers
>
> Here we have yet another IoT device that, from at least one person’s
> perspective is invading home privacy.  And again, it is the device itself
> that is the threat.  In this case, it’s probably a more manageable threat,
> because one can simply not get a NEST.  Try not getting a CPAP machine.
>
> And this brings us around to what layer to solve the problem at.  Some of
> this may need to be dealt with at layer 9 rather than at lower layers.  We
> should have that discussion too.
>
>
>
> Increasingly corporate networks are moving away from network layer access
> controls and using user authentication over TLS, so-called BeyondCorp
> model, including checking endpoint posture through management.
>
>
> The endpoint being the focus for attacks is very important.  As we shore
the endpoint up further, attacks may reduce in number, but will likely
increase in severity due to state sponsored actors.  Work in RATS, TEEP,
SUIT, and MUD should be considered in terms of how assurance of systems is
provided and also looking at the use cases to ensure there are sometimes
when you don't want that level of attestation.  User ownership of data is
another area.  These build on zero-trust/BeyondCorp/data-centric models and
are examples of active work in the IETF on the end point.  They also have
the potential to shift management and architectural models within the
enterprise.

Best regards,
Kathleen

> I don’t think this solves the railroad case.  Do you?  Just to clarify the
> example:
>
> According to their logs, two separate signals received  “set your lights
> to green” at the same time, causing two trains to crash into each other.
> According to the signal controller’s logs, it sent “set your lights to
> green” to only one signal.  What happened?
>
> All of the cases we are discussing have slightly different flavors of
> threats.  From an IAB program standpoint, the real question here is this:
> what are the architectural building blocks that are required?  Keep in
> mind, some of those blocks could be code and some could be policy.
>
> One goal should be code reuse. It is probably best that the people
> building the train signal *not* reinvent everything, but rather benefit
> as much as they can from the experience and results that you, EKR, and a
> great many other people have brought to society.
>
> Eliot
>
> (*) It’s also important to not fall into old tribal communication
> patterns, while recognizing the realities of the concerns raised by you,
> Watson, and me.
>
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>


-- 

Best regards,
Kathleen