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
- [dns-privacy] draft-ietf-dprive-dtls-and-tls-prof… Paul Hoffman
- Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-… Sara Dickinson
- Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-… Paul Hoffman