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

Michael Richardson <> Thu, 15 September 2016 01:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23E1912B122 for <>; Wed, 14 Sep 2016 18:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.388
X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, 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 XSVNdlnN2lOV for <>; Wed, 14 Sep 2016 18:32:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7AC7B12B129 for <>; Wed, 14 Sep 2016 18:32:27 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 87C952009E for <>; Wed, 14 Sep 2016 21:45:05 -0400 (EDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 4D9E16392D for <>; Wed, 14 Sep 2016 21:32:24 -0400 (EDT)
From: Michael Richardson <>
cc: anima-bootstrap <>
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: Wed, 14 Sep 2016 21:32:24 -0400
Message-ID: <>
Archived-At: <>
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 01:32:29 -0000

Michael Richardson <> wrote:
    > We had some significant discussions about the advantage of the NETCONF
    > "call-home" role reversal, and explained in this time sequence diagram that
    > has the TCP and TLS activities:


    > It was noting:  By flipping the TLS connection the handshake works out nicely
    > in our favor: the TLSCertificate payload is the 802.1AR cert and then
    > *after* it is authenticated the client could respond with the ownership
    > voucher cert  assuming the necessary extension could be defined.

having just read more TLS1.3 stuff...

ADDITIONALLY, TLS 1.3 is much more IKEv2 like, in that it does privacy first
              using an optional DH, and the client is expected to guess what
              the server wants, and if it gets it wrong, the server will use
              HelloRetryRequest to tell it what it wants.

So by reversing the things, we remove a bunch of guessing on the part of the
new pledge, and let the Registrar deal with supporting all ciphers/groups
under the sun, with the new pledge being deployed with only the latest useful
things (plus whatever gets defined as SHOULD+).

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