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

"Paul Hoffman" <paul.hoffman@vpnc.org> Thu, 27 October 2016 15:09 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA3C12996A for <dns-privacy@ietfa.amsl.com>; Thu, 27 Oct 2016 08:09:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ER-dxZF9lsNE for <dns-privacy@ietfa.amsl.com>; Thu, 27 Oct 2016 08:09:10 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 A36221294F8 for <dns-privacy@ietf.org>; Thu, 27 Oct 2016 08:08:40 -0700 (PDT)
Received: from [10.32.60.105] (50-1-99-230.dsl.dynamic.fusionbroadband.com [50.1.99.230]) (authenticated bits=0) by mail.proper.com (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 paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-99-230.dsl.dynamic.fusionbroadband.com [50.1.99.230] claimed to be [10.32.60.105]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Sara Dickinson <sara@sinodun.com>
Date: Thu, 27 Oct 2016 08:08:38 -0700
Message-ID: <C16CE173-233F-4D22-AFB7-D81291EE0639@vpnc.org>
In-Reply-To: <4B39F152-037C-488B-A9C2-61D198EE6227@sinodun.com>
References: <51FA1B3F-E955-48B0-8779-B8FA3E162184@vpnc.org> <4B39F152-037C-488B-A9C2-61D198EE6227@sinodun.com>
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: <https://mailarchive.ietf.org/arch/msg/dns-privacy/lt3l21y22Te_Fn7pRLbhyoDedDM>
Cc: dns-privacy@ietf.org
Subject: Re: [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: 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 <paul.hoffman@vpnc.org> 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