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

[Yoav Nir <[e-mail]>]

Hi

All comments below are made as an individual.

On Aug 11, 2013, at 10:36 PM, Trevor Perrin <[e-mail]>
 wrote:

> On Sun, Aug 11, 2013 at 11:53 AM, Yoav Nir <[e-mail]> wrote:
>> 
>> If I advertise a CAA record for my domain with the FQDN "instantssl.com", then InstartSSL will issue me a certificate, probably in an automated process. If instead, I say "comodo.com", this might be flagged, but probably authorized in the end. If it says "Kommodo", eventually a human is going to look at it and decide what the intent was, perhaps with a question by email.
>> 
>> In key pinning, this decision is entirely for a computer to make. So the browser will need to untangle the mess of domain names that certificate vendors own due to mergers, acquisitions, and simple branding. Worse - without a centrally-maintained list different browsers might untangle it differently, and administrators will have to guess what works.
> 
> CAs would tell browser vendors what names to use, and which keys those
> correspond to.  I don't think browser vendors should try to infer this
> on their own, as you're implying.
> 
> Having some sort of clearinghouse that aggregates info from CAs and
> makes it available to browser vendors might be useful.  But this is
> security-relevant info, so browser vendors might also prefer to query
> this from CAs themselves.

There is a third party here. The web site administrators need to set one of those strings in the key pinning data, so they should be able to obtain the correct strings. There may be only 3 browsers and half a dozen CAs that would want to experiment with this, but there may be a lot more web sites. The CAs could add it to their websites: "use 'ca.example.com' for RFC 7xxx key pinning". But I think we will get some pushback in either IETF last call or in IESG review if we try to kick it down the road.

> So there are design decisions here that I'm arguing can be kicked down
> the road.  In the short term (say the next year), we would be lucky if
> 3 browsers and a half dozen CAs wanted to experiment with this.  This
> is small enough that it can be coordinated manually.

Experimentation is tricky. A pin is matched if one of the keys match, so if use the example from the draft:

   Public-Key-Pins: max-age=2592000;
       pin-sha1="4n972HfV354KP560yw4uqe/baXc=";
       pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ="

The next time the UA connect it will check that the completed server cert chain has either of those pins somewhere in the chain.  Now let's replace the second pin with a named one. Assume that I have a certificate matching the first pin, but my next certificate is going to be from ca.example.com:

   Public-Key-Pins: max-age=2592000;
       pin-sha1="4n972HfV354KP560yw4uqe/baXc=";
       pin-named="ca.example.com"

When the UA connects again, the new certificate is there. The first pin no longer matches, so we need the browser to be able to verify that the new certificate matches ca.example.com. Once that is in some web sites, you can't stop the experiment. You'd have to go to each and every website that uses this pin and remove it. 

> If named pinning proves useful and lots of other CAs and browsers want
> to sign up, a more scaleable process can be designed then.

If I was assigned to do the SecDir review on this, I would push back on this.

Yoav