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

Randy Bush <randy@psg.com> Mon, 01 October 2018 22:44 UTC

Return-Path: <randy@psg.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E242A129619; Mon, 1 Oct 2018 15:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8rZNIa2OdhD; Mon, 1 Oct 2018 15:44:54 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7D2124C04; Mon, 1 Oct 2018 15:44:54 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from <randy@psg.com>) id 1g76vs-0001P4-8M; Mon, 01 Oct 2018 22:44:52 +0000
Date: Mon, 01 Oct 2018 15:44:51 -0700
Message-ID: <m2murxi8ws.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Christian Huitema <huitema@huitema.net>
Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, IETF Rinse Repeat <ietf@ietf.org>, anima@ietf.org, Security Directorate <secdir@ietf.org>
In-Reply-To: <057bd957-06b4-824e-a7c8-214383819621@huitema.net>
References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <m2sh1qkebi.wl-randy@psg.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net>
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: <https://mailarchive.ietf.org/arch/msg/secdir/fa5REqgYWWelXp4eKItdxrcbHWQ>
Subject: Re: [secdir] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=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
settings.

> 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 ....

right

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.

randy