Re: [websec] #58: Should we pin only SPKI, or also names

["Ryan Sleevi" <[e-mail]>]

On Mon, August 12, 2013 10:04 am, Gervase Markham wrote:
>  On 12/08/13 17:11, Trevor Perrin wrote:
> > If people hate this, someone should make a proposal for a registry:
>
>  Or make a proposal to stick with the current spec, and not pin names :-)

+1 to not pinning names.

>
> >> I think there will be problems with people not being protected who
> >> expect to be, if you allow this sort of pinning into the spec but leave
> >> entirely undefined the mechanisms for communicating what it actually
> >> should mean when someone pins to a name.
> >
> > Could you explain how these problems would arise?
> >
> > I'm proposing CAs would coordinate with browsers, then inform their
> > customers (websites) which name to use.  A misbehaving CA could inform
> > its customers of a meaningless name, causing browsers to ignore the
> > pin.  But a misbehaving CA could violate its customers' security in
> > other ways.
>
>  They would arise via any of the obvious mechanisms this could go wrong,
>  e.g.:
>
>  * CA fails to communicate with (some subset of) browsers, perhaps the
>  small ones, leading to divergent behaviour
>
>  * Browser update is not universally accepted, leading to divergent
>  behaviour
>
>  Say Foo CA merges with Bar CA, and issues an edict that from now on the
>  string "fooca.com" will include the already-deployed root, "Bar CA
>  Super-Secure". Six months later, after gnashing their teeth at the delay
>  that this process is introducing into their business, they start issuing
>  certs from "Bar CA Super-Secure" to Foo CA customers. A site,
>  naiveshop.com, is pinned to fooca.com, and buys one of these new certs.
>  All naiveshop.com's customers whose browsers are older than 6 months get
>  connection failures, and naiveshop.com can't easily detect that this is
>  happening, or to how many people.
>
>  Gerv


To echo Gerv, I think there are a number of real and practical problems to
the idea of pinning to names that make this even more error prone in
practice than pinning to SPKIs.

The most obvious one is how to distribute updates to names such that they
are universally accepted/recognized? An SPKI is an unambiguous identifier,
but a named layer of indirection creates issues, especially if names are
re-used (which is their whole value over SPKIs - is that they CAN be
reused for different sets of pins over time).

It's well known and understood that not every user updates their browser
every cycle. Or, when and if pinning is integrated into an OS, they don't
always update their OS. So you will quickly have a situation, very easily
within a few releases, of the name 'Foo CA' ambiguously referring to
multiple different sets of SPKIs.

This is independent of mergers - CAs that are issuing new intermediates,
or deprecating old roots, etc.

You also create an assumption that "User Agent == Root Store", which is
NOT a universal. There are a LARGE number of UAs (typically, smaller ones)
that do not operate their own root store, and even one of the most popular
UAs does not operate a root store across all their supported platforms. In
this situation, roots may be added/removed from the root store on a time
frame different from modifications to this proposed 'CA name list', thus
creating interop issues like the one Gerv highlighted.

Support for SPKI pinning relies on no other infrastructure - whether it be
the registry or the update mechanisms - and can actively be shown to work
in practice. The existing failure modes discussed in
http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08#section-4
highlight the need to balance usability with security, and the trade-offs
involved.

Adding two or three more parties into the pinning infrastructure seems to
trade security, add complexity, and not actually provide real benefit to
usability, because it still allows pin skewing, but of a different nature.

To me, this represents a similar attempt to create another situation like
the Public Suffix List ( http://publicsuffix.org/ ) - well intentioned,
and certainly valuable, but easily opening up a whole host of new security
and deployment issues.