Re: [secdir] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16

Randy Bush <> Mon, 01 October 2018 22:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E242A129619; Mon, 1 Oct 2018 15:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y8rZNIa2OdhD; Mon, 1 Oct 2018 15:44:54 -0700 (PDT)
Received: from ( [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F7D2124C04; Mon, 1 Oct 2018 15:44:54 -0700 (PDT)
Received: from localhost ([] by with esmtp (Exim 4.90_1) (envelope-from <>) id 1g76vs-0001P4-8M; Mon, 01 Oct 2018 22:44:52 +0000
Date: Mon, 01 Oct 2018 15:44:51 -0700
Message-ID: <>
From: Randy Bush <>
To: Christian Huitema <>
Cc:, IETF Rinse Repeat <>,, Security Directorate <>
In-Reply-To: <>
References: <> <> <>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [secdir] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Oct 2018 22:44:56 -0000

> The "soft fail" happens if devices need to be reset to factory
> settings for some reason, then you will have to wait for the
> manufacturer's servers to bring them back up.

when i sell the lightb^Hrouter to mary, of course i reset to factory

> That may be mitigated if the manufacturer provided you with nonceless
> vouchers, valid until "time=X", and in particular if the manufacturer
> gave you vouchers "good until infinity".  In that case, your old
> devices could still be reset to factory condition and restarted,
> without even "soft fail".

dear world: be absolutely sure that, when you buy a lightb^Hrouter,
you get a nonceless voucher with an infinite lifetime.  before handing
them your cash, you can test this by ....


how about the spec says that "the manufacturer MUST accompany the
lightb^Hrouter with a nonceless voucher with an infinite lifetime.
purchasers who, for whatever reason, with more restricted vouchers
may negotiate."

>> if the manufacturer's servers go down, either permanently or even for
>> a day, can i give/sell the device i have purchased to a third, well
>> fourth i guess, party, at my whim and seamlessly unencumbered?
> It depends somewhat on the type of voucher that the manufacturer is
> willing to give you, but the short answer is No, you can't.
> If the manufacturer only wants to provide real time vouchers that
> incorporate the random nonce issued by the device, then the answer is
> very clearly no, you cannot resell the device without approval from the
> manufacturer. The voucher in that case acts as a kind of DRM.

then i strongly object to the ietf specifying this; c.f. selling guns.
> If the manufacturer is willing to issue "good until time=X" vouchers,
> then in theory you could provide the voucher to your buyer, provided the
> time limit of the voucher has not elapsed. If the manufacturer signs a
> voucher "good until infinity", then the device can in theory be sold and
> resold forever. But that's probably not true in practice, because the
> voucher is written for a specific domain, and includes the certificate
> of the domain for which the voucher is good. You may be able to play
> games with some kind of certificate chain and make it work, but I will
> believe that when I see it.

i.e. practically you can not resell something you thought you had
bought.  baaaaaad.

> The BRSKI specification is a tradeoff and that's why I would really
> like to see the tradeoff explained in clear terms in the spec. It is
> designed to prevent hijacking of the device during its registration in
> the buyer's network.

if, to actually own a device i bought, i need to manage my own security,
then i will take that.

> If BRSKI implemented a pure RFC 7030 process, the device  might have
> to accept to be imprinted by the registrar without having verified to
> whom it is talking. In practice that would mean relying on some kind
> of physical security, or maybe relying on the kind of trust anchors
> commonly used for web services.  From the registrar point of view, the
> failure mode is that some kind of man-in-the-middle inserts itself
> during the registration process, and maintains control of the device
> after it is connected to the network.
> The voucher system mitigates that risk, but at the cost of strong
> dependency on the manufacturer. As I say, that's a trade-off, and I
> could see different buyers having different opinions on that
> dependency.  In fact, I could see buyers willing to buy devices only
> if they permitted "voucher-less" initialization. If the standard
> allowed that option, then market forces would quickly define how
> valuable the voucher system is.

two problems.

the buyer will not realize that they just rented the lightb^Hrouter
until they go to sell it; way too late to do anything about it.

the manufactures have very small incentive to lower drm barriers.
i can point to a jillion current examples.  my favorite of the week is
john deere.