[dns-privacy] draft-ietf-dprive-dtls-and-tls-profiles: SPKI pinning

"Paul Hoffman" <paul.hoffman@vpnc.org> Sat, 22 October 2016 23:25 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 803401294FE for <dns-privacy@ietfa.amsl.com>; Sat, 22 Oct 2016 16:25:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ZgEIzFAjskLN for <dns-privacy@ietfa.amsl.com>; Sat, 22 Oct 2016 16:25:42 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM []) (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 5EF25129472 for <dns-privacy@ietf.org>; Sat, 22 Oct 2016 16:25:42 -0700 (PDT)
Received: from [] (50-1-99-230.dsl.dynamic.fusionbroadband.com []) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u9MNPK18032834 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <dns-privacy@ietf.org>; Sat, 22 Oct 2016 16:25:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-99-230.dsl.dynamic.fusionbroadband.com [] claimed to be []
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: dns-privacy@ietf.org
Date: Sat, 22 Oct 2016 16:25:41 -0700
Message-ID: <51FA1B3F-E955-48B0-8779-B8FA3E162184@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.5r5263)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/2XDgyV4WgbDRum4zF90Ual1KwPE>
Subject: [dns-privacy] draft-ietf-dprive-dtls-and-tls-profiles: SPKI pinning
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Oct 2016 23:25:43 -0000

Greetings. The draft can't make up its mind about SPKI pinning. In 
Section 3, it says that SPKI-pinset-based authentication "is out of 
scope", but then immediately admits that "Section 10 does describe how 
to combine that approach with the domain name based mechanism described 
here". However, the draft also talks about SPKI pinning in 4.2, 4.3.2, 
5, 6, and then 10. Those sections suggest (sometimes indirectly) that 
you might want to check both DNS name and SPKI, but Section 10 then 
disavows specification of what to do if only one of the two identifier 
types match.

This is a mess. Either the draft has to give consistent, followable 
guidance or defer to a different document. The latter seems much more 
likely to get consensus than the former.


In Section 3 about what is out of scope:

o  SPKI-pinset-based authentication. This is defined in [RFC7858], and 
that document gives an example of a profile that uses them. The use of 
SPKI-pinset-based authentication is not discussed in this document, but 
might be addressed in a future document.

Then remove any mention of SPKI from the rest of the document (including 
the definition in Section 2). Also remove the bullet about raw public 
keys in Section 11, which seems completely out-of-place in a document 
about DNS name matching.

--Paul Hoffman