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

[Eliot Lear <[e-mail]>]

> On 28 Jan 2020, at 20:39, Stephen Farrell <[e-mail]> wrote:
> 
> 
> 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.

That is not my preferred solution, Stephen.  While industrial automation doesn’t really require encryption for most uses, I don’t think it can hurt, so long as the necessary auditing can take place.  Let’s focus on the problem first.  If we can agree on that, then let’s move on from there.

Eliot
> 
>> 
>> 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) <[e-mail]>
>>> sub   RSA 4096/36CB8BB6 2017-12-22
>>> 
>> 
>> 
>> 
>> 
>>> _______________________________________________
>>> Architecture-discuss mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>> 
>> 
> <0x5AB2FAF17B172BEA.asc>