[secdir] Secdir review of draft-ietf-trans-rfc6962-bis-39

Charlie Kaufman <charliekaufman@outlook.com> Sat, 03 July 2021 23:22 UTC

Return-Path: <charliekaufman@outlook.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 0CF7E3A2938; Sat, 3 Jul 2021 16:22:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 gdbCHWU95NtP; Sat, 3 Jul 2021 16:22:52 -0700 (PDT)
Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam08olkn2023.outbound.protection.outlook.com [40.92.45.23]) (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 252253A2937; Sat, 3 Jul 2021 16:22:51 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S1VJsSKcFAqriOw5l6TK1K9Q5DtAXpAVK/b3mMN2zZoqfFN5YfxATvA++Th5Z+sWxR5iwsi+aymtOmHTLlBvb7i4XPI6x4NS98Wkt/Eh4ZSKdtNc8OkPG23l8GkYI4HDNWgXNCELepTcMe/ecLkACmRyEGvO73leshp5TsuLKGKsDFTZ4d5p7ZOlM5jDFXFqfu8rvD8Z06oMD09VfV7SsBLivN93qF4ELA/F3QY7fV65oaf9OW6E9t0SVIqWkzC2uIGBjtW81pujmWxh+HQIM1AAdyFijPx57BffRklqHrc0ozTnRvY5OvJ5nhQDZS6bwISku8i5tNKgytsy2rfuww==
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=gqyLsgSyFJhMi30f8lWK4lJjudT+vr9WVavD7EU0Vtw=; b=TC7Yk1HdRwcJ+x4Ft2Oj/eXIblonm+CHJsqR1YvYR9G6/rmXRi6f5ysfPENHFtlJLhrOMrRY7xzxWH3Y7irsx+BXdfgB0FcIAE5lrhN6q35gZTBoJNl+LNrucXz7oRQjUyHPQJHVqmOo9bpNMiUZOAm+bHqax6+m34Pry0UJ3WPrnBbleQZnbeJGnEtGJYSPHL/+ogeRd3UmlUzKQZTUbubkB8LPR/N4NC9w9/0k/0/xpUnNUQpiLojwuvvgiZb200GY1DmM21iMAW3zkdXf1OyOl+Vj4sU/XSligKf+Sm6p2uhE39S7JMvHUvKaKvA4RdV6jwicuYRe0WTT4l2laA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gqyLsgSyFJhMi30f8lWK4lJjudT+vr9WVavD7EU0Vtw=; b=WgIkcgu1i5eMglNEXfC/p6rc+OwkURilcVhnZBAZXVovFRyfWlCy9fyrT569nMaNvd5W/206BpVbd3dC/7Y/TwuuwA3HqNQAbpcDMdx3ojaEFH45TgJuchLYc3ssOzlxlXSitYS6R/1RyayxdYkzOlIffrbA7lug/vjqMz3YBaXukOTB4VqAKVKTw7g0gWW3o69UPK22GzwdSjB3o+tIf1X+UTYByN8+ox413Ia8hdwRcnv7M0nkT49rFVq1/UwYbULuGGE2LwRGD8Dw3tCuSM3WghxjIZk7MNoGjVYWRZoaD1AvjJzJFm4JDmxEtE5WmgXV+i5DfLNF6ESeO5gS1Q==
Received: from DM6NAM04FT014.eop-NAM04.prod.protection.outlook.com (2a01:111:e400:7ea3::44) by DM6NAM04HT149.eop-NAM04.prod.protection.outlook.com (2a01:111:e400:7ea3::63) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18; Sat, 3 Jul 2021 23:22:50 +0000
Received: from MW2PR1901MB4683.namprd19.prod.outlook.com (2a01:111:e400:7ea3::49) by DM6NAM04FT014.mail.protection.outlook.com (2a01:111:e400:7ea3::288) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.22 via Frontend Transport; Sat, 3 Jul 2021 23:22:50 +0000
Received: from MW2PR1901MB4683.namprd19.prod.outlook.com ([fe80::f538:ebac:9440:4974]) by MW2PR1901MB4683.namprd19.prod.outlook.com ([fe80::f538:ebac:9440:4974%3]) with mapi id 15.20.4264.026; Sat, 3 Jul 2021 23:22:50 +0000
From: Charlie Kaufman <charliekaufman@outlook.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-trans-rfc6962-bis.all@ietf.org" <draft-ietf-trans-rfc6962-bis.all@ietf.org>
Thread-Topic: Secdir review of draft-ietf-trans-rfc6962-bis-39
Thread-Index: AQHXcGIc/cRwqgNbyk6UZeFj2ow23Q==
Date: Sat, 3 Jul 2021 23:22:49 +0000
Message-ID: <MW2PR1901MB4683075120F26ECC277DCBD4DF1E9@MW2PR1901MB4683.namprd19.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:75D5F8B729417261A596C4BF6CEE7D6BE4E102925E6BC2973504AE625440C8F8; UpperCasedChecksum:CC16E626F86A7DE2CD5F1914C54322B951DD7F502D70761A73D17FE7947B974D; SizeAsReceived:6959; Count:41
x-tmn: [pwAKGBqWQAjrASsMGfaATkiUdYCn/2NB/sI/EIS6YAOTFzd0po08/W7AnJdH1U9A]
x-ms-publictraffictype: Email
x-incomingheadercount: 41
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 22d3d800-623a-4292-eda0-08d93e797981
x-ms-traffictypediagnostic: DM6NAM04HT149:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: i8c/c9nsgFqOguRJwQMwX4dc1/nMW+bKPHTMOd8kRFwR6HDnn3y1r6P4yeUTbSuUCgQ/zFRsfWR/Dmr20t+rryls4dwaMiKWtKx7TxzoW3o5G5INbL3qN2SU4pzEwNdmnOGyxhGIOp2iArDNGgmWd0QJ2Mp1Q0tyslBkNn9MBnpof0eWLf8sK+WZ0YpvAb3S2f1jve0pPnHw5c/l4ZD9JNkVwOceA/QuU5Atl9K1mx2ze9uKP0NdWg68tG84gF//znkpGhnxRNXptTRnmWysieyQ9emx5ZAsusRBzYJ6mY/CUBaMMfn2qHMQYiOw5wPERtO34vjmLEFcrsoxTSLbIZVT499hcu9uW+CITwm+/1vEKoBCcTlbhZtQj5E8nmdmaZmGmyhOP7WnUAMDBOzh9ql9VPdMP7sg07kaz+zLOa6bZsiEIhScGatcBTWO7AHM
x-ms-exchange-antispam-messagedata: osKu9non5EQXGfmxRue7WpSTDZycpguk+3w0UjLRVW1gvihVkXuvPk6j9leJcZsdTpGYznnM05DlCSsXxIhPUEWWWtDm7fF8ArmMzbNRamRYf+pZ5gil6B85b3sAyrN1ZfS1sdc+Gq2mvP17UVvjLOAzzyQPhWmoPTUnrtDQdwzWUwgCnV0eVjzvcTROBiM9hpeIIp4Q0niILLRskE+ykA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: DM6NAM04FT014.eop-NAM04.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 22d3d800-623a-4292-eda0-08d93e797981
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2021 23:22:49.9099 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6NAM04HT149
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/UkBHCgs6Y2hBwDprkd26x4y6i7s>
Subject: [secdir] Secdir review of draft-ietf-trans-rfc6962-bis-39
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: Sat, 03 Jul 2021 23:22:55 -0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

I reviewed -31 two years ago, found no problems with it then, and examining the diffs find no problems with those either.

This is an interesting proposal for testing the validity of certificates in the Internet PKI (in addition to CRLs, OCSP, some DNS extension, and perhaps some others I'm forgetting), and it has functionality that overlaps with those. **PEOPLE INTERESTED IN TECHNICAL APPROACHES TO IMPROVING THE SECURITY OF THE INTERNET PKI SHOULD TAKE A LOOK AT THIS APPROACH WHETHER OR NOT THIS PARTICULAR PROPOSAL SUCCEEDS**.

It is a little odd that this is classed as experimental given that it appears to be deployed in Chrome and has enough history and evolution to be issuing a -bis.

The goal of this protocol is to prevent someone who captures the private key of a Certification Authority from issuing certificates for occasional use without the knowledge of the CA. It does this by registering all observed certificates in a log, encouraging clients to reject certificates not found in the log, and encouraging CAs to check the log for certificates signed with its key that were not signed through its authorized procedures.

The proposal specifies the actions of a partially trusted logging service that will take certificates as they are issued, sign an acknowledgement that can optionally be placed in the certificate itself or in the TLS headers during session initialization. The certificates are then placed in a Merkle hash tree and signed. This both reduces the signing work the log server has to do and allows it to prove that it has not removed any certificates from its database once they are posted there.

The protocol could be adapted for other logs that someone might want to audit for completeness and for following a policy of strictly-appending.

An interesting question that I did not see addressed in the I-D concerns whether the list of all issued certificates is made world-readable. The system assumes that the owners of particular domain names can watch for the issuance of bogus certificates for names they own, but many issuers do not want to make public the complete list of certificates they have issued for the same reason they would not want to release a complete list of DNS names they are using below their arc. DNS allows verification of guessed names but not enumeration of all names (at least optionally). Doing the same with this system would lose some of its security benefits, but not doing it would make it unacceptable to some issuers. This issue was discussed by the working group, but the security community might also want to comment.

	--Charlie