Re: [Anima-bootstrap] minutes from meetings since IETF97

"Michael H. Behringer" <> Fri, 10 March 2017 08:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E115B1293D9 for <>; Fri, 10 Mar 2017 00:24:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bx9jTHPvkwGf for <>; Fri, 10 Mar 2017 00:24:24 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE592126B6D for <>; Fri, 10 Mar 2017 00:24:23 -0800 (PST)
Received: by with SMTP id v186so4929650wmd.0 for <>; Fri, 10 Mar 2017 00:24:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=4/3GiF74wpIdDz7LLNLbyQ01aLIyrjtHvV7kAGzsZJg=; b=L6h1Y6UM79qAtuqvwbToXIrwkklSdYbZ/L9420stoT87YYk/QhJB2seNnDokuF8KHH 8hQSXaeZrmMQ35SevuKymiZWqa366UmnuxRx+aRvoAVUp6GMKAEzHoWSZZiM9yfkKLVI MMXnGtSG4Wt6CGlMZYrz1FEw7b75v0zlnoWgmUxe3kTq/ws2MvJkTyTU+fGloFHqPQk9 UtMXirU76dmZ6xXraVuTJjHHqW7xaS27YwLPQesJFDrRM2LkzEQyDqxQVdCTDavKx+os cJt3zQgyzhNgQbAGWjJxyw+p8dFCZnqkjqOAgJVfxol9bF6/mTGfUHMYy0/6oM1e8M2p D/uA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=4/3GiF74wpIdDz7LLNLbyQ01aLIyrjtHvV7kAGzsZJg=; b=pBmFBgxJTzTJsTjK+4HS6k46vrtiu18uEXp5lSSj5K9EyUXjahB1SmI3WwptPifyhK ozgNnLjzSyNrzmISlQxs7Eo4pukKVOAsqvCEh7Hvd71YYDhzOOcLDp+akSnQAk9BqWjW ThD50PlRKZ4hQyUpeFtBWQxRkzsbsFVQHHGISJf1XMWRGY1Y3mO0uflD+Pzc7jvDyzVP OWYZ0ZuS/sDCKlDp/xwqquGZMPaSObtmXfb3ooI/d9EmHKTqR7KN8U9umbd89QzKmjG2 QOsmXFDP2MIsskNi9us//jRRtFclYwf3T35b/P7eMeZCNVH0crbGo7SDvPyZeYle9mpV QvHA==
X-Gm-Message-State: AFeK/H28B0dG2zn+BNLY/BAli8loCKQxJ2uPhQn6kftlX6+GmU8y6Y4pNYaWsblEzB4Cwg==
X-Received: by with SMTP id b188mr1341324wmg.110.1489134262046; Fri, 10 Mar 2017 00:24:22 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id h3sm11726757wrb.6.2017. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Mar 2017 00:24:20 -0800 (PST)
From: "Michael H. Behringer" <>
X-Google-Original-From: "Michael H. Behringer" <>
References: <>
Message-ID: <>
Date: Fri, 10 Mar 2017 09:24:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Anima-bootstrap] minutes from meetings since IETF97
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: Fri, 10 Mar 2017 08:24:26 -0000

Hi Michael,

Sorry I haven't been attending lately, you may be aware of my employment change, which has changed priorities for a while.

However, I do plan to participate actively again and help bring all those docs to RFC. I'll be participating in the upcoming IETF, but only remotely, since I don't have a sponsor at the moment.

I'll be there on Tuesday.

A short request: I'm doing version -03 of the reference draft right now. If you see particular things from the bootstrap side that ought to be changed added in the reference draft, please let me know!


On 10/03/2017 02:47, Michael Richardson wrote:
These are the previous meeting minutes:" rel="nofollow">

If I've posted a summary since, I can't find it in the archives.

0) we continue to meet at 15:00UTC each Tuesday.
   Please see meeting details at:" rel="nofollow">

the members on the web site say:
    Max Pritikin (editor),
    Michael Richardson (editor)
    Jason Coleman,
    Sandeep Kumar,
    Michael Behringer,
    Alper Yegin,
    Bing Liu,
    Brian Carpenter
    Kent Watson
    Sheng Jiang (wg chair),
    Toerless Eckert (wg chair)

Typically we have the following people participate in the weekly calls.
       Michael Richardson
       Max Pritikin
       Kent Watson
   We are frequently joined by Toerless Eckert.
   We would welcome additional people/viewpoints.

But there are a number in the above list which we haven't seen recently.
Please chime in and tell us what you are up to, and what your take on the
current situation is.

The webex link is valid until IETF98.

We expect to meet on March 14, but note that north american clocks will
have changed, so it will be 11am EDT.
We keep running minutes using the etherpad. Yes there is a typo in the link.

1) we posted -04 of anima-bootstrap prior to IETF97, and have been working on
   the -05, which will get posted this weekend.

2) since October, we posted three versions of draft-ietf-anima-voucher
   (some under the previous names draft-kwatsen-netconf-voucher, and draft-kwatsen-anima-voucher).

3) all of the drafts are revision controlled in git, and hosted on, at" rel="nofollow">
   The bootstrap git tree contains a subdirectory minutes, which is the
   raw dump from the etherpad.

These minutes are organized by topic with ideas taken from the raw minutes,
rather than chronologically.

We agreed to the terminology proposed from the 6tisch-security
design team, and have made the changes in -05.  Another email
went to this list on that topic.

We discussed very early on what we would like to have to interoperate with
at the hackathon.  We concluded that exchange of vouchers and certificates
would make the most sense, even if we were using USB keys or web pastebins
for transport rather than HTTPS.
As of March 7, after many discussions that lead many places, we have
concluded that for IETF98, we will exchange JSON encoded vouchers
in PKCS7 containers such are easily produced by cli tools.

The voucher format is described at:" rel="nofollow">

and looks like:
     "ietf-voucher:voucher": {
       "assertion": "logged",
       "trusted-ca-certificate": "base64-encoded X.509 DER",
       "owner-id": "Registrar3245",
       "unique-id": "JADA123456789",
       "created-on": "2016-10-07T19:31:42Z",
       "nonce": "987987623489567"

The following table is now in the dtbootstrap-anima-keyinfra-05, section 2.2:

                  |Assertion   |Registrar ID    |Pledge ID | Validity    |
                  |Log-|Veri-  |Trust  |CN-ID or|serial    | RTC | Nonce |
                  | ged|  fied |Anchor |DNS-ID  |number    |     |       |
     Audit        |  X |       | X     |        | X        |     | X     |
     Nonceless    |  X |       | X     |        | X        |     |       |
     Audit        |    |       |       |        |          |     |       |
     Owner Audit  |  X |   X   | X     |        | X        |     | X     |
     Owner Role   |  X |   ?   | X     |  X     | X        |     | X     |
     Owner ID     |    |   X   | ?     |  X     | X        | X   |       |
     BearerVoucher|  X |       |   wildcard     | X        | ?           |
     MasterVoucher|    |       |   wildcard     | wildcard | X   |       |

we had a lot of discussion about how each kind of voucher can be used, and
what they mean.
We have come dangerously close to writing a Use Case / Requirements section/document.


Nonceless Vouchers can be issued in advance and stored for many years
and used when a device is finally deployed.  Reference to the owner by
CA+DN (rfc7093 provides a way) permits the registrar's key to be cycled
many times.

The question has remained: do we need a way to revoke vouchers?

If the answer is yes, we considered that maybe the vouchers should be cast in
PKIX format as if they were certificates, such that we could use the same
kind of CRL or OCSP mechanisms.  We are not yet convinced of this;
but we do think that we could include a serial number in each voucher
such that we could, even if the voucher was not in PKIX format, use
OCSP with that serial number.  This discussion remains open.

What definitely came out of this is that we need more text to explain
how each voucher-type should be used to address particular deployment
scenarios.  From that, we also need to better define the deployment
scenarios, probably giving them easily discussed names.

After much discussion, we decided that the operational security problems with
providing for a bearer token lead us to conclude that we do not want to
standardize one.  We think that there are other ways to do almost the
same thing.


We discussed having the voucher be in JWT format, as described in RFC7519,
RFC7517, etc.  This would also permit switch to CWT format as described
in draft-ietf-ace-cbor-web-token.  This discussion is not over, but
for the purposes of IETF98, this is out of scope.

A JWT/CWT might look like:
    "iat": 1478854302,
    "nbf": 1478824302,
    "exp": 9999999999,
    "cti": "987987623489567"
    "logged": "true",
    "aud": "base64-encoded X.509 DER",
    "sub": "JADA123456789",


We had a discussion over a few meetings about the how much we needed to say
about pledges that see multiple Join Proxies, and which have the CPU/RAM to
attempt to enroll over all proxies at the same time.

One of the reasons to do this is because it eliminates concern where an
attacker (operating a rogue proxy, or a fake JRC) attempts to sabotage the
enrollment process by very slow TCP communications.  The goal would be to
annoy the operator who them chooses a less secure alternate mechanism, or the
vendor provides some kind of backdoor.  Setting "appropriate" timeouts
could (and should) be done, but this may result in failures when the
network is simply very congested.  Doing the work concurrently avoids having
any one attempt hold up the others; but as soon as one attempt succeeds,
other attempts would be abandonned.  We did not figure out how much
text we need add about this, but we feel that there are no protocol concerns
with concurrent join attempts.

   AI: The M_FLOOD vs mDNS initial discovery discussion is not over, and
   we should invite the DNSSD/mDNS folks to come and make the case.

   This remains an Action Item, and we need to reach out to the
   proponents of mDNS to more clearly articulate the reasoning behind their
   preferences, and also to clearly explain how they would use mDNS.
   A major difference seems to be that mDNS would not support a passive
   (listen-only) mode for the pledge.  It would have to do a multicast
   discovery for the service, announcing itself to the entire network.

  We have removed the CoAP mechanism until we prepared to properly
  define it.

  We have added an appendix to explain the IPIP proxy mechanism.
  It is no longer a MUST.

Continued GRASP Proxy/Registrar discussion

A thread was posted to the list already about how we should properly do
discovery of the registrar by the Join Proxy.


Our WG chair has suggested that it is time to close the anima-bootstrap list.

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-

Anima-bootstrap mailing list" rel="nofollow">