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

"Paul Hoffman" <> Thu, 27 October 2016 15:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4EA3C12996A for <>; Thu, 27 Oct 2016 08:09:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ER-dxZF9lsNE for <>; Thu, 27 Oct 2016 08:09:10 -0700 (PDT)
Received: from (Opus1.Proper.COM []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A36221294F8 for <>; Thu, 27 Oct 2016 08:08:40 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.14.9) with ESMTPSA id u9RF8ckQ020170 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Oct 2016 08:08:39 -0700 (MST) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: Paul Hoffman <>
To: Sara Dickinson <>
Date: Thu, 27 Oct 2016 08:08:38 -0700
Message-ID: <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.5r5263)
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 15:09:14 -0000

On 27 Oct 2016, at 5:35, Sara Dickinson wrote:

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

Yes, that seems fine, if the tidying-up is complete. I was completely 
thrown by the "Scope" part, but this sounds reasonable.

--Paul Hoffman