Re: [Iot-onboarding] what can pinned-domain-cert actually pin?

"Owen Friel (ofriel)" <ofriel@cisco.com> Mon, 16 September 2019 09:49 UTC

Return-Path: <ofriel@cisco.com>
X-Original-To: iot-onboarding@ietfa.amsl.com
Delivered-To: iot-onboarding@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019BB12081C for <iot-onboarding@ietfa.amsl.com>; Mon, 16 Sep 2019 02:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=epdEupdf; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=cQP/vp6R
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 dafAAF-J5XLJ for <iot-onboarding@ietfa.amsl.com>; Mon, 16 Sep 2019 02:49:41 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A89120810 for <iot-onboarding@ietf.org>; Mon, 16 Sep 2019 02:49:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3269; q=dns/txt; s=iport; t=1568627381; x=1569836981; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MvOJrYTxH1Rj7qEl59tumD6TDW4hPIsY0raouXsdrEA=; b=epdEupdfP0AImC+pMvGQTAVkInoU0IzEGaKcL1fuKQpjqc0bV8Mig5cT Vv0j2qSUAyvxh/yJxtocvkksdBhez6d20Rf7aXhltRONxm6fbSs+HrAxm curUg8wyooHg7+hw27qCH+HG7rxusgqAeUcJ0hOVImwUy3bpCQsk6iEm7 Y=;
IronPort-PHdr: =?us-ascii?q?9a23=3Akm5DBReQsxDXSLRoMXg9kQn0lGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwKYD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/aCIgHclGfFRk5Hq8d0NSHZW2ag=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAAALWn9d/4kNJK1mGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBVAUBAQELAYFEJCwDgUMgBAsqCodeA4pwglyXcYEugSQDVAkBAQE?= =?us-ascii?q?MAQEtAgEBgUuCdAKCbSM1CA4CAwkBAQQBAQECAQUEbYUuDIVKAQEBBBIoBgE?= =?us-ascii?q?BNwELBAIBCBEEAQEBHhAyHQgCBA4FCBqEawMdAZ8vAoE4iGGCJYJ9AQEFhQo?= =?us-ascii?q?YghcJgTQBiiQQgUMYgUA/gRFGgkw+hEaDO4ImrG4KgiKVG5kZikWcRgIEAgQ?= =?us-ascii?q?FAg4BAQWBVAE1gVhwFYMngkKDcopTc4EpjioBgSIBAQ?=
X-IronPort-AV: E=Sophos;i="5.64,512,1559520000"; d="scan'208";a="332672654"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Sep 2019 09:49:40 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x8G9nea8020987 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 16 Sep 2019 09:49:40 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 16 Sep 2019 04:49:40 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 16 Sep 2019 04:49:39 -0500
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 16 Sep 2019 04:49:39 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ehXfqa2Mp8fq3RCCQkuTrLf2ahZ52XaGWhoLp52DtGFckDQPmQ4YbUNeHrb+CLJCx4BCDVWjDFzdHxKkCrK5uGpnD0aFIeNk0UVooJ/ya/9q8y2EB3WTUdg0jV6mrXysNfLBufA3J94qLWU7MXZMLW/Hn7mXV/f1eA1bnpt8k9dYlWflvPcYybUxhAKhf2gIL/iPrqPXrSHazS5G6H6jfcGk/4OKuRP96rQnE+gGroGNrLNZMGxj6Zjh+30BVf3+dYogd1/zMHJEDvi0FN9Hk54ZIw9YMG0jeP5cRIUpbVUKba4/ywcLMyYG8HT7tkU3SIZcjo+1kpMjHx3fymFg7g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rwQjVQKQIh60MXR3PftCEZV2lE+ZwjKKGy0bjgekLxI=; b=FV+t/BcqtjPTolBnwwpjRKn0eEpg8vat4E2aBkF8DVY65xRG0w9QVEmiS17JnwZwzuSqSky6dJHevGUk6fXDlE5H0A9nitndQqghTXnG+OE2xagsOsYSd64wQioXLJ7ztyY5kPwgLxxCxIfhCgvgb2e9LyURdoH35CZSXdngTK28yvYIEnfWtvPIRdR969BqiXFa4yT2QqGEmrSblw476ZnWRS8ekOIBR7vv0oAA0jOkC6cNccz5+w13b+3pz01wTrIwChjgaiH0kwbzYZFhB1dykQQ6lS1E5tYRB3pIujQALiMewYe07i2rz4/DpHBmqxycNRFo1oQDOApROBS+eQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rwQjVQKQIh60MXR3PftCEZV2lE+ZwjKKGy0bjgekLxI=; b=cQP/vp6RoC2fBlU2ekouUbIcBSA7iqL6aOCMzsznCyuqdoukh6C4qvSVV6N4o92bWdtlcBTUCFuozOtB/0raXBA0UfR1hrI7/d6wvPnq2ZdOSNmtosTovUatUiYsA7pP69/6hQYkGnnx223dO6j/2v8m7CfvAUc+NX3/O6AfNs4=
Received: from CY4PR1101MB2278.namprd11.prod.outlook.com (10.172.76.13) by CY4PR1101MB2277.namprd11.prod.outlook.com (10.172.77.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.23; Mon, 16 Sep 2019 09:49:37 +0000
Received: from CY4PR1101MB2278.namprd11.prod.outlook.com ([fe80::686a:2f6e:32c2:5127]) by CY4PR1101MB2278.namprd11.prod.outlook.com ([fe80::686a:2f6e:32c2:5127%9]) with mapi id 15.20.2263.023; Mon, 16 Sep 2019 09:49:36 +0000
From: "Owen Friel (ofriel)" <ofriel@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
CC: "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>
Thread-Topic: [Iot-onboarding] what can pinned-domain-cert actually pin?
Thread-Index: AQHVXPTdRdfIG1V6k0+L04J9EcMpEqcPVJEAgADrXPCAAIPLgIAAWrWggAFceQCAAQdCAIAAqXWAgBoBb3A=
Date: Mon, 16 Sep 2019 09:49:35 +0000
Message-ID: <CY4PR1101MB22784B197ADBC6ABE3865C50DB8C0@CY4PR1101MB2278.namprd11.prod.outlook.com>
References: <2693.1566923418@localhost> <0100016cd46359e7-8c844438-dc7a-45df-9868-ba0957bcc89f-000000@email.amazonses.com> <CY4PR1101MB22782817AA5A55C3812A3EEFDBA30@CY4PR1101MB2278.namprd11.prod.outlook.com> <12883.1567010221@localhost> <CY4PR1101MB22788341CC8F7D5EBB72C33EDBA30@CY4PR1101MB2278.namprd11.prod.outlook.com> <16322.1567104534@localhost> <CY4PR1101MB22789600E60FFA85053CEFDFDBBD0@CY4PR1101MB2278.namprd11.prod.outlook.com> <2318.1567197459@localhost>
In-Reply-To: <2318.1567197459@localhost>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com;
x-originating-ip: [64.103.40.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b49256a5-4385-4559-49aa-08d73a8b2f07
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:CY4PR1101MB2277;
x-ms-traffictypediagnostic: CY4PR1101MB2277:
x-microsoft-antispam-prvs: <CY4PR1101MB2277F8AA98811E3A4E172B53DB8C0@CY4PR1101MB2277.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4502;
x-forefront-prvs: 0162ACCC24
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(136003)(366004)(376002)(346002)(13464003)(51444003)(189003)(199004)(478600001)(71200400001)(9686003)(66066001)(7736002)(5660300002)(229853002)(256004)(86362001)(14444005)(486006)(186003)(446003)(476003)(11346002)(6436002)(55016002)(25786009)(2906002)(14454004)(316002)(6116002)(3846002)(4326008)(64756008)(52536014)(6246003)(53936002)(71190400001)(102836004)(66556008)(81156014)(8676002)(66476007)(66946007)(76176011)(66446008)(7696005)(53546011)(6506007)(33656002)(76116006)(8936002)(99286004)(74316002)(305945005)(26005)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1101MB2277; H:CY4PR1101MB2278.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: E+RPbT8SnTb6BL3tIwAINy+beIhhGkB0xS5i1Eokph5NZn/q3x0ka9hlqH1BrF/0lvOIzUahtj5G1Lhq88ygxadu86aJ/YnGFyN2vVDHIrMK83Fc+V1nPo3Ctkj3TVzaXneDjhTJUlpe+uoZxw8UWvYqOpTnhR2KclBELijpdCK+RZDdN1u6fx2HK2Etf20oNezg/hzrPYOkI4Ray8IPXlbAS/ErQvZiU8YC/6LQ3K5fc0Bjg43kw3Jo9NJZbW3Qxlau/tl0dUxSo521kAZfDMjKVT7tlKrBtE5AX5pEals6L6Gx9FlokRZ7VbaOxOPJ3zaG2ly/3EOb7448LYl71wO5rvZgNLux+y3oyzXUOh19DhjYF/F3QOKvMO+hvOq8dT/o7N550l5emVbQg1acaAbxL2UKBOuwkdqciO9SX48=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b49256a5-4385-4559-49aa-08d73a8b2f07
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2019 09:49:35.7407 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: jC3ZJQMFy9V9g9sytFI0rFIlkKeeXPQpFDnh8lp8yMiu5P+wesNSua9tHxOZ9cGXZU5o5GIp7vRGKBNDi9WRzA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1101MB2277
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/BF4UvzvmvfHlswWBohTCHesTphA>
Subject: Re: [Iot-onboarding] what can pinned-domain-cert actually pin?
X-BeenThere: iot-onboarding@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IoT onboarding mechanisms <iot-onboarding.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-onboarding/>
List-Post: <mailto:iot-onboarding@ietf.org>
List-Help: <mailto:iot-onboarding-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 09:49:44 -0000


> -----Original Message-----
> From: Iot-onboarding <iot-onboarding-bounces@ietf.org>; On Behalf Of Michael
> Richardson
> Sent: 30 August 2019 21:38
> To: Owen Friel (ofriel) <ofriel@cisco.com>;
> Cc: iot-onboarding@ietf.org
> Subject: Re: [Iot-onboarding] what can pinned-domain-cert actually pin?
> 
> 
> Owen Friel (ofriel) <ofriel@cisco.com>; wrote:
>     >> > Regardless, LE root rotation is not at issue here. The issue is what
>     >> > happens if an operator wants to move from GoDaddy to
>     >> > LetsEncrypt. Either (i) all existing vouchers are dead or (ii) we need
>     >> > multiple pinned-domain-cert entries. And maybe (i) is fine and if an
>     >> > operator wants to change root CA providers, then the operator sucks it
>     >> > up and reissues all nonceless vouchers.
>     >>
>     >> We could also consider pinning the public key of the Registrar.
>     >> This is how constrained-BRSKI works.  There are crypto-hygiene issues
> here,
>     >> but maybe it's better than putting more fragile logic into a device that
> might
>     >> remain on a shelf for many years.
> 
>     > Right. You could pin the raw public key and then the RA EE cert could
>     > rotate provided the key remained the same. Obviously any changes to the
>     > key (length, algorithm, etc.) invalidate vouchers.
> 
> Depending upon what kind of processing we could assume on the pledge (thus
> the tussle), one could imagine that if the key/algorithm/etc. became too weak,
> that one could use the key to sign another stronger certificate to be used going
> forward.
> 
> This doesn't make the key stronger suddenly, but unless the key is actually
> compromised, it allows the old nonceless vouchers to be used in the future.
> 
> My take is that this is a lot of code effort in the Pledge.
> If the Enterprise/Registrar would cause to be operated a long-lived private
> CA, then the problem goes away.   It doesn't have to be operated by the
> Enterprise itself; it could be operated by a service provider that they trust.  In
> effect, it's just a new form of MASA.
> 
> I think that this is really the right way to go: to allow chains of vouchers pinning
> keys, which can then be used to issue new vouchers (which could pin new keys).
> This solves the long-term problems you have mentioned, and removes the
> external dependancy upon a MASA.... by createing a new dependancy upon an
> internal MASA.

I am not convinced that allowing chains of vouchers pinning keys is simpler that allowing a voucher to have 2 or more pinned-domain-certs. In fact, I would the code in the pledge to support chains of vouchers pinning keys is probably more complex than the code to allow an array of pinned-domain-certs in the voucher. With any TLS library code I have ever messed with, you setup the trust store to include your set of 1 or more CAs, and the TLS stack takes care of everything once the trust store is setup. If you have a chain of vouchers pinning keys - then that's all application specific code.

> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>;, Sandelman Software Works  -=
> IPv6 IoT consulting =-