[secdir] review of draft-ietf-stir-certificates-10.txt

Klaas Wierenga <klaas@wierenga.net> Tue, 25 October 2016 14:01 UTC

Return-Path: <klaas@wierenga.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B5155129541; Tue, 25 Oct 2016 07:01:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id KemcvfzphzJY; Tue, 25 Oct 2016 07:01:39 -0700 (PDT)
Received: from out23-ams.mf.surf.net (out23-ams.mf.surf.net []) (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 CA10512966F; Tue, 25 Oct 2016 07:01:16 -0700 (PDT)
Received: from mail.het.net.je (mail.het.net.je []) by outgoing1-ams.mf.surf.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id u9PE1EDk031617 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 25 Oct 2016 16:01:14 +0200
Received: from 52d95635.cm-11-1b.dynamic.ziggo.nl ([] helo=[]) by mail.het.net.je with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <klaas@wierenga.net>) id 1bz2HE-0004Df-Ns; Tue, 25 Oct 2016 16:00:28 +0200
From: Klaas Wierenga <klaas@wierenga.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
Message-Id: <50455A6C-3C51-408C-927C-26711D3B7370@wierenga.net>
Date: Tue, 25 Oct 2016 16:01:13 +0200
To: The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-stir-certificates.all@ietf.org
X-Mailer: Apple Mail (2.3226)
X-Antivirus: no malware found
X-Bayes-Prob: 0.0001 (Score 0, tokens from: p-out:default, p:default, base:default, @@RPTN)
X-CanIt-Geo: ip=; country=NL; latitude=52.3824; longitude=4.8995; http://maps.google.com/maps?q=52.3824,4.8995&z=6
X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default)
X-Canit-Stats-ID: 0uRXO1ekQ - 92781f050718 - 20161025 (trained as not-spam)
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/4KPw_MxdGAllfqMnrL4pQ7fTGus>
Subject: [secdir] review of draft-ietf-stir-certificates-10.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 25 Oct 2016 14:01:41 -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.

draft-ietf-stir-certificates-10.txt describes the use of certificates to assert authority over phone numbers. 

The document is clear and I believe addresses the security concerns surrounding the use of certificates in this context. I consider this document:

ready with nits

I have a few questions though, probably to do with my lack of understanding of the use case, so I hope you will indulge me:

- pardon my ignorance, but would ENUM/E.146+DNSSEC be an alternative too? It seems to me that DNS works better than lengthy certificate chains….

- section 5.2: doesn’t using 1 certificate with millions of numbers defeat the purpose of this work? Could one of those million numbers spoof another of those numbers?

- section 10.2: "The requirement to consult OCSP in real time results in a network
   round-trip time of day,” I don’t understand that sentence.