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

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 22 Oct 2016 16:25:41 -0700

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.

Proposal:

In Section 3 about what is out of scope:

o  SPKI-pinset-based authentication. This is defined in [RFC7858], and 
that document gives an example of a profile that uses them. The use of 
SPKI-pinset-based authentication is not discussed in this document, but 
might be addressed in a future document.

Then remove any mention of SPKI from the rest of the document (including 
the definition in Section 2). Also remove the bullet about raw public 
keys in Section 11, which seems completely out-of-place in a document 
about DNS name matching.

--Paul Hoffman

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 27 Oct 2016 13:35:59 +0100

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

Regards

Sara.

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 27 Oct 2016 08:08:38 -0700

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

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

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

--Paul Hoffman