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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 28 January 2020 19:48 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 6DB2E120045 for <architecture-discuss@ietfa.amsl.com>; Tue, 28 Jan 2020 11:48:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 HXTn-Xn-_q2q for <architecture-discuss@ietfa.amsl.com>; Tue, 28 Jan 2020 11:48:20 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BB8C120033 for <architecture-discuss@ietf.org>; Tue, 28 Jan 2020 11:48:20 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1BF47BE20; Tue, 28 Jan 2020 19:39:15 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uj_TMlJ7erSR; Tue, 28 Jan 2020 19:39:12 +0000 (GMT)
Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A01B3BDCF; Tue, 28 Jan 2020 19:39:12 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1580240352; bh=Wg2AcaYs3/k4+9JtzMGkjUwQnIl+FEqaRz80j5n1O3U=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=sPnWa5HvTyPPdIb/6nRwQ5yWTJwjkwPyEPPa8qr+HhiKPEPqHDN6isP6bdZtBfdET Xkcm2Ssldc6ddlzbaxQVgus/UN9I1iLKgWdLNV2uAiabpsvVyAH29H8cSHJzUGIcTr NMAPrU5ZHaJXI6ENiRuY2496ekalQp5wHgF8xMRM=
To: Toerless Eckert <tte@cs.fau.de>
Cc: Eliot Lear <lear=40cisco.com@dmarc.ietf.org>, Watson Ladd <watsonbladd@gmail.com>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>, model-t@iab.org
References: <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> <20200128192305.GR14549@faui48f.informatik.uni-erlangen.de>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <f999e0bd-47fa-da79-6661-7bf38873b9d3@cs.tcd.ie>
Date: Tue, 28 Jan 2020 19:39:11 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <20200128192305.GR14549@faui48f.informatik.uni-erlangen.de>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rdtr0Cl7sTrpaKKxkSDxvIXIPgwQbLbqN"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/abGSIodb7s4qfpVhU_k9EGm03GE>
Subject: Re: [arch-d] 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 19:48:23 -0000

Hiya

Offlist for two reasons...

On 28/01/2020 19:23, Toerless Eckert wrote:
> Stephen,
> 
> I totally do not get how you read Eliots text as being about TLS.

He and I have chatted about this before - one of the
options he maybe like for his train example is a NULL
encryption ciphersuite to be standardised/recommended
(as opposed to defined) for TLS1.3. I think that'd be
a bad plan.

> 
> I read Eliot/Watsons mails to be in the same direction as what i was
> pointing out yesterday.

2nd reason for offlist is that I'm not getting what you
mean below, but I'm pushed for time right now, so maybe
reading it later will make it clear;-) In any case, it'll
be a while 'till I get to respond, sorry.

Cheers,
S.

> 
> Let me try to abstract maybe better:
> 
> In the past, we have primarily looked at the security implications
> of individual protocols, communicating mostly between two endpoints
> and attacks against this communication by observers, MitM, or
> malicious endpoints.
> 
> Of course, we went beyond that but not systematically to the point that
> instead of concentrating only on the communication channels, we would
> instead concentrate also on the properties of modules whose complete
> external behavior is defined through a set of interfaces. And then
> define security properties observing that superset of interfaces.
> 
> Once you have this model, Watson/Eliots examples are easy translated
> into propagation properties between these interfaes.
> 
> My yesterdays mail points was more about the problem of having
> modules that are small enough or implemented in a way that at
> least specific properties can be verified instead of just having to
> trust the module vendor. Or having interfaces that allows another
> module to verify/control behavior. 
> 
> Of course, the fun difference with this model is that in the most
> simple of cases, you could try to view a complete router as one
> of those modules, because vendors of such gear have a great interest
> to well define and expose all interfaces of such a device, wheras a typical
> communications endpoint such as an application server in a data-center
> is more often than not built around a business model where exposure/
> definition of all interfaces would expose bad business practices.
> Hence also political approaches like GDPR to start addressing
> that problem.
> 
> Cheers
>     Toerless
> 
> On Tue, Jan 28, 2020 at 10:02:43AM +0000, Stephen Farrell 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.")
>>
>> 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). Changing the security properties of widely
>> deployed cryptographic protocols is not likely to be a
>> useful approach to attempt, as there are too many
>> deleterious side-effects of such proposed changes."
>>
>> 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.
>>
>> Cheers,
>> S.
>>
> 
> pub   RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) <stephen.farrell@cs.tcd.ie>
>> sub   RSA 4096/36CB8BB6 2017-12-22
>>
> 
> 
> 
> 
>> _______________________________________________
>> Architecture-discuss mailing list
>> Architecture-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/architecture-discuss
> 
>