Re: [OPSAWG] "Secure Device Install" - draft-wkumari-opsawg-sdi

Bill Fenner <fenner@fenron.com> Sat, 30 March 2019 09:16 UTC

Return-Path: <fenner@fenron.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A671C120188 for <opsawg@ietfa.amsl.com>; Sat, 30 Mar 2019 02:16:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fenron.com
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 KlbLHOv5QD68 for <opsawg@ietfa.amsl.com>; Sat, 30 Mar 2019 02:16:31 -0700 (PDT)
Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7D3A120193 for <opsawg@ietf.org>; Sat, 30 Mar 2019 02:16:30 -0700 (PDT)
Received: by mail-ua1-x930.google.com with SMTP id d5so1501110uan.6 for <opsawg@ietf.org>; Sat, 30 Mar 2019 02:16:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fenron.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9/Dn2qp8k3nz9iH3S2L+uq75aSgUMkpDwR5cplSOdgg=; b=JWYeHfrYULO1KvPe5tB7nRsckzY1lYEoq7ca3wEwL8RvGQzreOFfNsC+7sDZuJ/HfB n6ocAczaGtuU1Mfe+IT4TfAKwaQFZgo4ZnqNWSFMXKrxOFu0OjqsrgT0PhUhJk3fEssQ B4NJOYVugy0QewFtXIHX4AiOVwCQQIno9Eyqc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9/Dn2qp8k3nz9iH3S2L+uq75aSgUMkpDwR5cplSOdgg=; b=SjCI6NjCeV1Zzl1Jh052AuoxDzC6d5oLLHZ1HclNXsfLt809+WEIjJjp3GtToVsXWS fn89WpuL2cTu+Rqj3HuY+5GLkglBONk2Aqriq0cq24wYv+9SD3B7hJFlrDm+5ChSDdz4 WngSUrP4wsP9UBWKNtsYvJyujMLIKNLn/SNGfqfNmetEjMndMntXc8y+FrRiQFBkdT5C bwwWshpt6PFJe+ezo9ueKIcfJCoLY0jgXBqJuSf1bA/3GHXIZLBeZxNpbKtBWB2yxCus GuEOIddGw3XUvjWPQd8988rkLbosE99NmQJ2BGMzCG3etyIlBYk3o30Msy/ZXJ/g+SyE gepQ==
X-Gm-Message-State: APjAAAX5LUK6WBfri1TGOUQtCWkO1EQqUIGJl9SUbj69gkRWu06zC+ie HzXZ+4ppVFcooGZcLivSoAxNqwxW6FgjDCe1uYqZVC3ER8oIzaKx
X-Google-Smtp-Source: APXvYqypTWC2bEV7Vtoa69mqS0HGTq0YTTTi0/quaETeGOaRW20hy0CsPqqg18alclg2ZLh0tXhcZoAyFG9OqnPvN8c=
X-Received: by 2002:ab0:26c5:: with SMTP id b5mr31167418uap.13.1553937389768; Sat, 30 Mar 2019 02:16:29 -0700 (PDT)
MIME-Version: 1.0
References: <CAHw9_i+ddD3bHAtG2uo7UQh3X52eOsEzMdkg3z_Q0kHe7XDs5A@mail.gmail.com>
In-Reply-To: <CAHw9_i+ddD3bHAtG2uo7UQh3X52eOsEzMdkg3z_Q0kHe7XDs5A@mail.gmail.com>
From: Bill Fenner <fenner@fenron.com>
Date: Sat, 30 Mar 2019 10:16:18 +0100
Message-ID: <CAATsVbYKgrXSoz1jJ7f9W6-wi-iajo3ktYEQJXrqMrRi=tVhiA@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
Cc: OPSAWG <opsawg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001eeb8705854c3e21"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/IpkPTSkHsmhPlHDnZBUtNnC9Ooc>
Subject: Re: [OPSAWG] "Secure Device Install" - draft-wkumari-opsawg-sdi
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Mar 2019 09:16:33 -0000

Hi Warren,

The idea is interesting.  I definitely like the idea of having a
lightweight mechanism for this - certainly customers have been asking for
"secure no touch provisioning", whatever that means.  I'd like to throw out
a couple of things for discussion:

1. Vendors (speaking as one) don't necessarily want it to be easy to find
out what serial numbers we've built.  You may say "well change your serial
number allocation", but, we have a whole logistics team that has way more
input to that.  Also see https://en.wikipedia.org/wiki/German_tank_problem .

2. If we create an identifier divorced from the serial number (e.g., a
UUID) to avoid problem 1, we still need to provide that identifier to the
customer somehow. The serial number is nice because it's written on the
device, so you can tell which one you've got when you have a stack of 150
that you just received.  Perhaps there can be a service provided by the
vendor that performs the dynamic mapping, but then that service is
vulnerable to the dictionary attack to discover serial numbers (or needs to
have countermeasures).

3. The vendor is now responsible for maintaining the public key until the
user needs it.  Sure, storage is cheap, sure, I can back it up on Google
Cloud, but that's still a new burden on the vendor (no matter how light
weight it sounds).

  Bill