Re: [Anima-bootstrap] DRAFT minutes up to 2016-09-13

[Michael Richardson <[e-mail]>]

Brian E Carpenter <[e-mail]> wrote:
    >> Brian E Carpenter <[e-mail]> wrote:
    >> >> I) The ANIMA cast list is as follows:
    >> >> i) pledge is TCP-initiator, TLS-client, HTTP/EST client.
    >> >> ii) registar is TCP-responder, TLS-server, EST server.
    >>
    >> > Where's the proxy in that? And didn't we say we'd also have a COAP option?
    >>
    >> The proxy is in between, but doesn't provide functions above layer-3ish.
    >> I ommited it for clarity :-)

    > OK. But layer 4 probably - it seems likely that we would terminate a TLS
    > session at the proxy and make another one between the proxy and the
    > registrar. (That's the bit I *didn't* model in my Python demos.)

No, we don't want to do that for a number of reasons:

In no particular order:

1) The proxy isn't trusted, and doesn't know how to trust the pledge.

   While it has a local domain certificate, it has no knowledge about the
   Manufacturer Installed Certificate (the IDevID) that the pledge provides.

   The pledge has no way to trust the proxy: this is what the ownership
   voucher is for (and causes us some challenge to get right), and I don't
   think we want to extend the trust conveyed by the ownership voucher to the
   network operator, transitively, to all of the operators' machines.

2) The proxy may not have resources to terminate a possibly large number of TLS
   connections.  We want to make being a proxy as inexpensive as possible,
   particularly given that this function (along with the rest of the ACP
   processing) likely resides on a control plane CPU.




--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-