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

Christian Huitema <huitema@huitema.net> Mon, 01 October 2018 05:43 UTC

Return-Path: <huitema@huitema.net>
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 08C711286E3 for <secdir@ietfa.amsl.com>; Sun, 30 Sep 2018 22:43:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 kZsTeuftMZbX for <secdir@ietfa.amsl.com>; Sun, 30 Sep 2018 22:43:07 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 795E1126F72 for <secdir@ietf.org>; Sun, 30 Sep 2018 22:43:07 -0700 (PDT)
Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx105.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1g6qz1-0001gD-Ih for secdir@ietf.org; Mon, 01 Oct 2018 07:43:04 +0200
Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1g6qyz-0005EZ-Hp for secdir@ietf.org; Mon, 01 Oct 2018 01:43:02 -0400
Received: (qmail 2373 invoked from network); 1 Oct 2018 05:42:59 -0000
Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.42.134]) (envelope-sender <huitema@huitema.net>) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for <secdir@ietf.org>; 1 Oct 2018 05:42:58 -0000
To: Randy Bush <randy@psg.com>
Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, IETF Rinse Repeat <ietf@ietf.org>, anima@ietf.org, Security Directorate <secdir@ietf.org>
References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <m2sh1qkebi.wl-randy@psg.com>
From: Christian Huitema <huitema@huitema.net>
Openpgp: preference=signencrypt
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <057bd957-06b4-824e-a7c8-214383819621@huitema.net>
Date: Sun, 30 Sep 2018 22:42:55 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <m2sh1qkebi.wl-randy@psg.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 168.144.250.230
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.44)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5qfirOTVaLBQGbvtAYDwnqF602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzniiMFxnOFMHTZqw+apvQzTV/3OdXD2Xdo8CfrY5CQSexc6rQWlPuhmVv85H/HTKIyz NJVaeAWax4WOe4pTBX2DwIE7VKe+bqpcdCns72R1/fRcQ8DPjRRdBSJfnAogVbUJ8oN+d2/1YClf NOnZIS+k7MxK87c44TynDTcugpM/kRBtrTRM/4TRHmTy40yDhnXc9h1jP0GCLUBD5fsSyyeBaQIi fdaGzMoXcgXnOXfsRAwX31WVY5lWjWxuGSRuxURW8UvT0kUDO7BO02wlaiMJNrZqjoiSWdcjcZLv /Am2ptBB9icD2fnZzw/HNF6wGm/P3Q658NtotfOVlwP9Y9difvX7GxYM34o1TppnqMQvRsaiauSV ohXqcOBLfm7uY6BmNlijRSWQzbBZx5Si4hrQHolQlVdf0A32Xtl5FAWD8PcNYjhf2jycpxDLnRQv ahqZR3KVQgqF/fPYYAfEfsjRCeh3Vga/K+tTXg3EW+ZCQyYzoTs9p0wBCDqWWHnNC0XDy76XUbBI c8kzcy5u9YnFVfV8YwbQTud2ndj194c9/49qryIYbFFBOkVCXXzvNoACQcwXnrT9jVUoMBm9/34R FZ4oobg8BBg3Jq+ntzj0/EZUYLcD59sOzzNgwf0NQS6m92U/Rr2NiuKWX4lMKSlFQJWvCSfS5UB2 KOwdnKnPUcrFDkA/NjAbu3DqdC3lyMStknsMa5xMcOok/WzPHhmu7ALr9GwxDinRa92sptNCgXQb 9W4Kqgrdo/qlHQwR1/JNukDO91giXRCq1+m63CgzzZ1TJCc1Jsz93JxBBgxpJBPvPDjBPaowofdk fHH45mUVrBsPGnNiJ83AD/4JscB0VTS+bY/ezHW1Vxxj2dVmDKpXV/g3aWnksZpz4kAf+OlNC4wc 2LkM7XQE4YLVklOegMwrtwdodggrHZMuX9HK
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/XMfvQOPMK_lg1_3Rm_T71tK6OKw>
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 05:43:10 -0000


On 9/30/2018 11:52 AM, Randy Bush wrote:
> christian,
>
> a stunning review as usual.  but i have two questions which you kind of
> finessed.  they are simple binary, i.e. yes/no, questions that the end
> user, to whom the IETF is ultimately responsible, really cares about.
>
> if the manufacturer's servers go down, either permanently or even for
> a day, does the device i have purchased still work?  i.e. is it fail
> soft? [0]

My understanding is that, yes, the device that you have purchased and
installed still works. BRSKI is a bootstrap service, and as Michael
Richardson says, the dependency is only there during the bootstrap, i.e.
between the time you unwrap the device and the time initialization on
your network is complete.

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

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

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.

> fwiw, i asked these same questions at the 2005 paris side meeting at
> l'ecole whatever hosted by mark.  the blank stares i received alarmed
> me.  the ietf is ultimately responsible to the users.

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

-- Christian Huitema