[arch-d] Yes, building blocks ; -) Re: not building blocks (was: Re: [Model-t] Possible new IAB program on Internet trust model evolution)

Eliot Lear <lear@cisco.com> Tue, 28 January 2020 11:33 UTC

Return-Path: <lear@cisco.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4C9BF120013 for <architecture-discuss@ietfa.amsl.com>; Tue, 28 Jan 2020 03:33:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Y_H6RYOa__ok for <architecture-discuss@ietfa.amsl.com>; Tue, 28 Jan 2020 03:33:46 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94E5120018 for <architecture-discuss@ietf.org>; Tue, 28 Jan 2020 03:33:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9936; q=dns/txt; s=iport; t=1580211226; x=1581420826; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=g2IFCPFvMfy6H/Xk+gZlDj9RF4gQu3lnR3qCqEwddjk=; b=aXnTh6yiGgqFRc5Ty2aBEZAJku65PKaUGB0xKlxgrONJMkQp24EyWu7l FvkO9oqDrFi/K7jjO4296wwBw61vZDhDWmOWTPE50W5TpPo2Y0qFm5j/r 2bIoDvcBVGZg1pz1Y/RhnsQlCyUn7v+BarVbHRV9QTR6kfZuakH+a9t8D o=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.70,373,1574121600"; d="asc'?scan'208,217";a="22687500"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jan 2020 11:33:43 +0000
Received: from ams3-vpn-dhcp4134.cisco.com (ams3-vpn-dhcp4134.cisco.com []) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 00SBXhf0001230 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Jan 2020 11:33:43 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <2B1BEC89-D6DF-4E7A-9171-63257BDCFFA6@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_27B9B0D0-26F5-4F1A-9EBB-93BBB904C3AE"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
Date: Tue, 28 Jan 2020 12:33:42 +0100
In-Reply-To: <6efc8e84-90fc-aadc-ce3a-784051a9f6b3@cs.tcd.ie>
Cc: "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>, model-t@iab.org
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
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> <6efc8e84-90fc-aadc-ce3a-784051a9f6b3@cs.tcd.ie>
X-Mailer: Apple Mail (2.3608.
X-Outbound-SMTP-Client:, ams3-vpn-dhcp4134.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/2Q9LgmieBBjoGs6WyB4GaiW5LE8>
Subject: [arch-d] Yes, building blocks ; -) Re: not building blocks (was: Re: [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 11:33:50 -0000

[Last message of the day for me, promise.  Thanks for your patience.]

Hi Stephen,

I know I’ve said this in the past, but I hope we’re actually agreeing more than disagreeing here.  See below.

> On 28 Jan 2020, at 11:02, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> Hiya,
> On 28/01/2020 06:44, Eliot Lear wrote:
>> From an IAB program standpoint, the real question here is this: what
>> are the architectural building blocks that are required?
> I'm not sure I agree. ISTM you envisage a programme that
> tries to establish that existing IETF consensus as to the
> use of e2e encryption needs to be changed, which I don't
> think is a goal here. Personally, I think of this as a
> place to work on whether or not it's possible to extend
> (not replace) the 3552 threat model to cater for changes
> since 3552 was written. (I do think that's an interesting
> question and it's unclear to me if the answer is "yes" or
> "would like to, but it's not usefully feasible.")

3552 a great document! It provides great guidance for a very common usage pattern. As such, we should tread very carefully, but tread we must, no?  I do not suggest we replace it, but rather examine assumptions and its applicability.  Christian’s comment is apt: do we assume that devices are safe because they are disconnected?

> Now, it's of course valid to point out that comsec (as
> ekr may put it) if applied e2e doesn't by itself meet
> all requirements stated in your examples, to which I'd
> maybe argue to extend the Internet threat model with
> some statement along the lines of: "if an endpoint
> does need to see traffic content or significant meta-
> data, then you need to design your protocol so that that
> endpoint is an endpoint at which relevant cryptographic
> mechanisms are validly terminated, according to the
> expectations of the cryptographic protocol(s) in use (e.g.
> TLS, IPsec).

I really don’t know what expectations a protocol has, but if part of an existing code base / specification can reasonably satisfy clear and well justified requirements, I would rather beg, borrow, and steal than rewrite, so as to capitalize on past experience.  That’s not to say we should change any existing protocol, but rather depend on the parts we can leverage.

> So I don't think, for the purposes of this exercise,
> we're considering existing widely deployed protocols as
> malleable building blocks, whether that protocol is
> TLS or some (deployed) train signalling system.

Building blocks must be stable and not malleable so that others can depend on their behavior.  I hope we don’t look at any single example to design those blocks, which is why I raised several; I hope others would raise others, as Watson did; and I would suggest that this program take a walk before run approach.

In summary (otherwise known as burying the lede), my suggestion is to test / validate these sorts of examples, maybe decompose as required a bit of what we have “on the truck” into various components that could prove useful, pick from the best, create the rest, and then demonstrate value.(*)


(*) There is probably a separate more general question hiding here as to how we build protocols, and what is the right granularity for their constituent parts.