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

[Toerless Eckert <[e-mail]>]

Stephen,

I totally do not get how you read Eliots text as being about TLS.

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

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


-- 
---
[e-mail]