Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
From: Sara Dickinson <sara@sinodun.com>
In-Reply-To: <51FA1B3F-E955-48B0-8779-B8FA3E162184@vpnc.org>
Date: Thu, 27 Oct 2016 13:35:59 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4B39F152-037C-488B-A9C2-61D198EE6227@sinodun.com>
References: <51FA1B3F-E955-48B0-8779-B8FA3E162184@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/8kFlh6-H04Uo9dWrn6kkwgHhLwE>
Cc: dns-privacy@ietf.org
Subject: Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-profiles: SPKI
 pinning
Precedence: list


> On 23 Oct 2016, at 00:25, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>=20
> 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.
>=20
> 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.=20

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.=20

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.=20
- These mechanisms may be used independently or together. If used =
together all mechanisms must succeed for the authentication outcome to =
be successful.=20
- tidy up the references you pick out based on this, for example, update =
references to =E2=80=98a valid domain name or SPKI pinset=E2=80=99 to =
=E2=80=98a valid authentication mechanism=E2=80=99 or similar

I hope that would provide a clear and consistent picture? If so I can =
work on that update.=20

Regards

Sara.=20