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

Charlie Kaufman <charliekaufman@outlook.com> Fri, 03 May 2019 03:41 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 0BE401201D5; Thu, 2 May 2019 20:41:03 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 FFZ5ozJcnMCK; Thu, 2 May 2019 20:41:00 -0700 (PDT)
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-oln040092010028.outbound.protection.outlook.com [40.92.10.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63D9D1201D0; Thu, 2 May 2019 20:41:00 -0700 (PDT)
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=ovkTXwXYlRGSQ/YS1FFr2xWQWFuaXqxiNUjypO4m+aA=; b=CkzlpR7zSmenlJkVl7VYZkGUN54FvMZozQXXlP7RdZiyDadyeG5g7Q4z7Zn1WUCj0UMJ9qjoqkOoRkfnWjbSLio0EoZY6mZpe1SaeUstWM90m227bjUL5Pd+dm+ynRPWsD0DYXXyNMzy2Slas+cn9kAQ81KDA9cu/a+i0UrrXXhLJWru5hcg+dpHd9BqHVDfxoqix6y/V8KfJaszNVq26YY0rlmiwQjalSDDW5uOSrsIm/u02K7WfBKN7PZPP1/tpLs59rSq08vvJt+tT431Gz1s6QVhStyXNhcavediGXTLp+lHfN5HTuoS5+XHYCLVmUs+rBUKNaX9QgjDfR8QTg==
Received: from CO1NAM04FT028.eop-NAM04.prod.protection.outlook.com (10.152.90.56) by CO1NAM04HT169.eop-NAM04.prod.protection.outlook.com (10.152.90.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1835.13; Fri, 3 May 2019 03:40:59 +0000
Received: from MWHPR04MB0367.namprd04.prod.outlook.com (10.152.90.53) by CO1NAM04FT028.mail.protection.outlook.com (10.152.90.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1835.13 via Frontend Transport; Fri, 3 May 2019 03:40:59 +0000
Received: from MWHPR04MB0367.namprd04.prod.outlook.com ([fe80::30f9:fd17:40d1:98f9]) by MWHPR04MB0367.namprd04.prod.outlook.com ([fe80::30f9:fd17:40d1:98f9%9]) with mapi id 15.20.1856.008; Fri, 3 May 2019 03:40:59 +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-31
Thread-Index: AQHVAWHdS1kjPoUHZk6rW20pTOXzgw==
Date: Fri, 3 May 2019 03:40:58 +0000
Message-ID: <MWHPR04MB03679D2785C09BB3A86BD970DF350@MWHPR04MB0367.namprd04.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:963111EC8F592F3340B141FEBEDF61E1A82A6ED8F26091F8355C1D15031E59A2; UpperCasedChecksum:A3192B3BE64721D8455D87668AC544CE26D90F5C55C9B0C132990CF214867148; SizeAsReceived:6807; Count:40
x-tmn: [07ggZCwpAJrPx5+dbu7DA4EgyHE6qQZKK8ruxT9wSEorxHYZ4IehnwV0tdiauZVB]
x-ms-publictraffictype: Email
x-incomingheadercount: 40
x-eopattributedmessage: 0
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(5050001)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031323274)(2017031324274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:CO1NAM04HT169;
x-ms-traffictypediagnostic: CO1NAM04HT169:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-message-info: xf2EoGRHCiXv3AnstsTW2B9Y3pHi5OpCqkLu134DpyIKQvXqKgargwJMaNLKxB2WQ9gdoaUIQkq3E2wOimoV15gLLDLIh0Oh4G0QvQOL6FzO4DMxF2YDJJlG+5L+MLbA8qJF749kUSeuanC5iO158qMwx736PChU6zGqV5aQt3j4KtNRSvqBGwTdbJu5zhQP
Content-Type: multipart/alternative; boundary="_000_MWHPR04MB03679D2785C09BB3A86BD970DF350MWHPR04MB0367namp_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 1334b1e0-902d-4742-3ebb-08d6cf79281f
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2019 03:40:59.0022 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT169
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/pm1d4S6ETTNw-SR_zKa4QthEEAU>
Subject: [secdir] Secdir review of draft-ietf-trans-rfc6962-bis-31
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: Fri, 03 May 2019 03:41:03 -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.

[**Note: This review is very late and likely moot. I was a few weeks late because I was travelling, then noticed I had missed the deadline and asked Tero whether there was any point in my reviewing this. He said "probably not" so I didn't, but it appears writing a review is the only way to get it off my secdir assignment list. So this will not be up to my usual standard**]

I'm a little confused by a procedural issue. RFC6962 is experimental, and this revision is also proposed to be experimental. I didn't think that revisions to experimental protocols got the designation "bis", but perhaps I was misinformed.

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

The idea may have been inspired by the success of block chain in other contexts, and proposes that all certificates that Internet users are expected to accept when they are presented should be published for all to see to give people the opportunity to watch for invalid certificates being issued for names they control so that they can complain about them.

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.

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.

 --Charlie



Sent from Outlook<http://aka.ms/weboutlook>