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

Brian E Carpenter <> Tue, 28 January 2020 18:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3FB93120025 for <>; Tue, 28 Jan 2020 10:46:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1
X-Spam-Level: *
X-Spam-Status: No, score=1 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, FREEMAIL_REPLY=1, HK_SCAM=1.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4CV_YvdsYRQb for <>; Tue, 28 Jan 2020 10:46:35 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::1043]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 60D51120026 for <>; Tue, 28 Jan 2020 10:46:35 -0800 (PST)
Received: by with SMTP id r67so1460823pjb.0 for <>; Tue, 28 Jan 2020 10:46:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0SrB4nT6nvVgikt51fyxXvGZBYxHZY3MRaweNo0Zyto=; b=ce1X36c1m/BCYnbO2YGeW5Vll7NhcxbVtDj6ExZsF13yviF1KA0bv5VRfummhklHcH CU8i9Zuz9Cd7dmc5souq3YYmev4S2rTpfdim8prE587E7faw/iYfQbJSXrQoDn+b+QsV IWy8wRlXoC3vz66Chi3cjKtoVGYVAReJshgn03LCOmlogLHWdzR2oWqQuYAu2RQFJpRV vEL6uNh5VBbP6tv0aBEyrf5AnvwO9/SBB6l+SEomci6UEMtPzfYHtzHs34rRgJ+DmlUm n+vZIcZk9kBYRUXyF1Af3SI//PsvlEy9B04I782qy33zUDlB/krqzMYz9XTbLQXpM4ip pVdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=0SrB4nT6nvVgikt51fyxXvGZBYxHZY3MRaweNo0Zyto=; b=CvbSM2rbrN8k0EaDSrKM+z5gK8SzByWe9FXLjmDkCMuix1KJWWZbju6lGujUxmtp/Z F4q4pLQgN7GgROBjbXXcV8/3+OYAq2MmUXWcg82W6EWbom+6Q9V6hGIXmenkxYET7YTQ iG8kT6+Wr/Zf8kHP669R8FMWMl5giweYAvP72vTMbDdyDWzNmy496QB+zXQhZLA9QOFc 5Vv0TvP0P8Hs29RzQIyc5ys/AP1242oX/p8+Hv4/vYBKDxyhheQExulQexCRo0RPseyb 6JMJzCfpYkBN4FWJ+lwcX2jOT/Zs24bpT43DvxtHE0kz7LMtyu56KmXPzvCfmTEqGcKl poqg==
X-Gm-Message-State: APjAAAUj7JKCvVTeng1gkzTwwTS/QGfqVcN1ld46U7FmDjd7UXVTwpbZ ET6QIFx0waEF5tTDKReihG8=
X-Google-Smtp-Source: APXvYqynwVjckXfblZmG9skSugL53pDbqHTVUMN56FW40SXdwE25Tzfc6G8liP2mTgPCStWHK51y2w==
X-Received: by 2002:a17:90a:8a08:: with SMTP id w8mr6338953pjn.125.1580237194672; Tue, 28 Jan 2020 10:46:34 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id i127sm21165952pfe.54.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jan 2020 10:46:34 -0800 (PST)
To: "Joel M. Halpern" <>, Eliot Lear <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Wed, 29 Jan 2020 07:46:28 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Jan 2020 18:46:37 -0000

On 29-Jan-20 04:16, Joel M. Halpern wrote:
> I am a bit concerned by the emphasis on what appear to be application 
> policy, business policy, or government policy.  To the degree that these 
> are decoupled from the technology we define, my impression is that the 
> IETF is neither skilled at nor influential with regard to these topics. 
> We can spend a lot of time and energy on them.  They are interesting 
> topics.  But are they really our business?

Joel, I think they are part of the threat model (exactly as we have argued
in RFC1984, RFC2804 and RFC7258). In that sense they are absolutely our business.
Just in the last few days, key escrow has been back in the news, for example.

Ultimately, technology influences policy, so our choices are not without


> Yours,
> Joel
> On 1/28/2020 1:44 AM, Eliot Lear wrote:
>> Hi Watson,
>>> On 28 Jan 2020, at 02:35, Watson Ladd < 
>>> <>> wrote:
>>> On Sun, Jan 26, 2020 at 1:44 AM Eliot Lear < 
>>> <>> 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.
>> 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.
>> 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