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

Sara Dickinson <> Thu, 27 October 2016 12:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B281129446 for <>; Thu, 27 Oct 2016 05:36:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1uo1ka3sNN4M for <>; Thu, 27 Oct 2016 05:36:13 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9467F129519 for <>; Thu, 27 Oct 2016 05:36:12 -0700 (PDT)
Received: from [] (port=20837 by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from <>) id 1bzjuY-0004My-8U; Thu, 27 Oct 2016 13:36:09 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
From: Sara Dickinson <>
In-Reply-To: <>
Date: Thu, 27 Oct 2016 13:35:59 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Paul Hoffman <>
X-Mailer: Apple Mail (2.3226)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id: user confirmed/virtual account not confirmed
Archived-At: <>
Subject: Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-profiles: SPKI pinning
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Oct 2016 12:36:15 -0000

> On 23 Oct 2016, at 00:25, Paul Hoffman <> wrote:
> 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.

I agree that the current draft is muddied with these additional references but I think this is actually a relatively easy fix. 

The intension in the document was to treat as out of scope the details of _how_ to do SPKI authentication as they are described in RFC7858. What is (implicitly) in scope is how SPKI authentication can be used as an authentication mechanism within the general Usage profiles. 

So I would proposed clarification following lines:
- Re-word the Scope along the above lines
- Clarify that the Usage Profiles depend on the outcome of authentication (and encryption).
- The authentication outcome is the result of one or more authentication mechanisms. Currently available mechanisms include SPKI authentication as described in RFC7858 and the domain name based authentication as described in this draft. 
- These mechanisms may be used independently or together. If used together all mechanisms must succeed for the authentication outcome to be successful. 
- tidy up the references you pick out based on this, for example, update references to ‘a valid domain name or SPKI pinset’ to ‘a valid authentication mechanism’ or similar

I hope that would provide a clear and consistent picture? If so I can work on that update.