Subject: [websec] dual meaning of "pinning" [was: Re: [Uta] Proposed list of deliverables]

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 20 Jan 2014 10:44:40 -0500

On 01/20/2014 06:51 AM, Alexey Melnikov wrote:
> http://datatracker.ietf.org/doc/draft-melnikov-email-tls-certs/
> http://datatracker.ietf.org/doc/draft-moore-email-tls/

Both of these drafts use the term "pinning" in line with the way it is
used in RFC 6125, which is in contradiction to the way the term
"pinning" is used in websec's Key Pinning draft:

 https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

In 6125 and the two e-mail drafts above, "pinning" is used to refer to
the activity that firefox describes as "adding a security exception" and
chrome calls "proceed anyway" -- where the user (or someone) overrides
the TLS verification stack to indicate that a particular certificate is
acceptable to them for a particular site, regardless of the name or
other entity identifiers found in the certificate.  I'd call this
"permissive" pinning, since it increases the set of acceptable
certificates in general.

In the draft-websec-key-pinning, the term "pinning" is used to indicate
a set of keys (not certificates) that the server communicates to the
client which *must* be used for future connections to that server.  I'd
call this "restrictive" pinning, because it reduces the set of
acceptable certificates in general (certificates that are signed by
other trusted root authorities over end entity keys that aren't in the
set of pins will be considered unacceptable).

Even worse, these two "pinning" ideas could overlap for a particular
browser/website: a site could use the restrictive key pinning to
indicate which public keys are acceptable, and then offer a certificate
over one of those keys which isn't signed by a root authority accepted
by the client; so the client would need to "set a security exception" or
"proceed anyway", which is forbidden by draft-ietf-websec-key-pinning
(section 2.6).  But it's also possible that the user already added a
"permissive" pin (a "security exception") for that web site before
receiving draft-ietf-websec-key-pinning pinning instructions from the
web server :/

I think we're heading for trouble with this terminology overlap, in a
space that is already difficult to understand for implementers, server
administrators, and browser users.  but i don't know how to best avoid
further confusion.

In the server administration circles i travel in, people who are
security conscious tend to associate the term "pinning" with the ideas
behind draft-ietf-websec-key-pinning.  If you tell them that "setting a
security exception" in firefox is also "pinning", it will cause no small
amount of concern (since their goal in deploying public-key-pinningis to
avoid having their users tricked by an MITM offering bogus
certificates).  OTOH, RFC 6125 itself is published, so its meaning of
"pinning" won't be going away any time soon :/

At the very least, it seems like new drafts should make it clear that
their meaning of "pinning" does not mean the other well-known "pinning".

Any better suggestions for avoiding the ambiguiity?

	--dkg

---

From: Chris Palmer <[email-masked]>
Date: Mon, 20 Jan 2014 10:57:53 -0800

> chrome calls "proceed anyway" -- where the user (or someone) overrides

(Note that Chrome does not remember your decision to Proceed Anyway,
although we are working on that.)

> their meaning of "pinning" does not mean the other well-known "pinning".

Perhaps "key pinning" vs. "exception pinning"? I wanted to call
"exception pinning" "name pinning" at first, until I remembered DNS
pinning (to defend against
http://en.wikipedia.org/wiki/DNS_rebinding). So maybe we have 3
pinnings. :) It's worth noting that 2 of the 3 (key pinning and DNS
pinning) refer to *reducing* the number of trusted entities.

Anyway, I consistently refer to the behavior described in the key
pinning draft as "key pinning", if that helps. (Probably not.) I can
add an explanatory note to our draft, if that would help.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 20 Jan 2014 16:55:18 -0500

> although we are working on that.)

ah, that's good to know, thanks for the heads-up.

> pinning) refer to *reducing* the number of trusted entities.

Hm, RFC 6125 pinning is also about certificates, not just public keys,
so maybe it's "certificate exception pinning" -- but really it seems
like a flavor of permissive TOFU (trust on first use) more than anything
else.

so we have:

 * DNS pinning: maintain DNS records in the browser (possibly past their
TTL) to avoid DNS rebinding attacks.

 * key pinning: binds public keys to domain names (at the request of the
origin server), forbids the use of certificates that do not include the
pinned public keys somewhere in the cert chain.

 * certificate pinning: associate an otherwise non-valid End Entity (EE)
certificate with a domain name (at the request of the user), permitting
that certificate to be used with the domain name, but *without*
forbidding any other certificate from use.

> pinning draft as "key pinning", if that helps. (Probably not.) 

I think it's a start, at least.

> I can add an explanatory note to our draft, if that would help.

I think a clarifying note in draft-ietf-websec-key-pinning is necessary
(i don't know that it is sufficient).  it could be just something to
indicate that the key pinning described in the draft  has entirely
distinct semantics and characteristics than "RFC 6125 certificate
exception pinning".

	--dkg