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

Michael Richardson <> Thu, 15 September 2016 12:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E240212B5A5 for <>; Thu, 15 Sep 2016 05:52:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.409
X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W7J1ha4hn-rW for <>; Thu, 15 Sep 2016 05:52:30 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DD3AE12B54D for <>; Thu, 15 Sep 2016 05:49:35 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id E5ED8E1D6; Thu, 15 Sep 2016 09:02:17 -0400 (EDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 169AE6392C; Thu, 15 Sep 2016 08:49:35 -0400 (EDT)
From: Michael Richardson <>
To: Brian E Carpenter <>
In-Reply-To: <>
References: <> <> <> <>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Thu, 15 Sep 2016 08:49:35 -0400
Message-ID: <>
Archived-At: <>
Cc: anima-bootstrap <>
Subject: Re: [Anima-bootstrap] DRAFT minutes up to 2016-09-13
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Sep 2016 12:52:32 -0000

Brian E Carpenter <> wrote:
    >> Brian E Carpenter <> 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 <>, Sandelman Software Works
 -= IPv6 IoT consulting =-