Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-00.txt

[Yaron Sheffer <[e-mail]>]

Hi Daniel,

Thanks for your review. Please see my comments inline.

	Yaron

On 10/11/2015 11:48 PM, Daniel Kahn Gillmor wrote:
> Hi Yaron--
>
> On Sun 2015-10-11 15:57:38 -0400, Yaron Sheffer wrote:
>> We have a standard for certificate pinning (RFC 7469), but it is rather
>> hard to use and as a result is rarely deployed. This draft proposes a
>> lightweight alternative that allows TLS clients to authenticate the
>> server they're connecting to, even if a rogue CA can generate fake
>> certificates for that server.
>>
>> The draft is currently TLS 1.3-only, and is based on the previous draft
>> of 1.3 so some minor details may have changed.
>
> I've only just skimmed thus far, but i'm happy to see this proposal.  A
> few comments below:
>
> TACK
> ----
>
> As you note in the draft, it addresses a similar problem as TACK, which
> never made it through the standards process:
>
>    http://tack.io/draft-tack.html
>
> perhaps it would be useful to have a section next to the Comparison:
> HPKP that included a Comparison: TACK ?
>

I'm not familiar enough with TACK at the moment. I can write something 
up, or if you'd like to contribute text, that'll be awesome.

>
> (dis)similarity to session tickets
> ----------------------------------
>
> In the session-ticket case, most servers (clustered or otherwise) can
> afford to treat their session ticket master keys as ephemeral keys -- if
> the server is restarted or dies and is re-installed, the worst that
> happens is that a client doesn't get to resume their session -- they
> have to open a new connection.
>
> If the session ticket resumption master keys are used as recommended
> here, it seems like the risk of master key loss is bricking the server,
> so the master key becomes necessary to store non-ephemerally.
>
> Writing the master key to disk or storing it off-site someplace can
> present a risk to the forward-secrecy of ticket-resumed sessions.
>
> tracking the master key itself seems like it also adds specific
> operational overhead for server maintainers that doesn't currently
> exist.  Does this reduce the advantage of the scheme over TACK or HPKP?
> if not, can you explain why not?
>

IMO persisting the master key to disk is less of a problem than 
distributing it across cluster members, and this is something that needs 
to happen or session resumption will fail regularly. Regular  rotation 
of the master key means that persisting it to disk is not such a risk. 
You are right that a session resumption master key needs not be backed 
up, whereas the pinning secret may need to be backed up securely for 
disaster recovery.

>
>
> Client Privacy
> --------------
>
> section 6.6 says "TODO", and page 5 says:
>
>>        The main reason for refreshing the ticket on each connection is
>>        privacy: to avoid the ticket serving as a fixed client
>>        identifier.  It is RECOMMENDED to include a fresh ticket with
>>        each response.
>
> If the participating client wants privacy from the server (to avoid the
> server using this to track the client) but also wants defense against
> broken CAs, how does recomending this behavior from the server actually
> allow the client to enforce privacy?
>
> The server is trivially capable of tying together a history of
> pinning_ticket objects to track specific clients, right?  it just
> remembers the two tickets involved every time it generates a
> PinningTicket extension.  If the pinning tickets returned by the server
> are different each time, the client cannot know whether the server is
> doing this tracking or not.
>

Yes, I was thinking of privacy in the face of passive attackers who 
listen in to the TLS handshake. Not when the server itself is out to get 
you. I suspect that there is little you can do to protect your privacy 
when the server itself is malicious, but I'm sure you are more 
knowledgeable about these issues.

>
> public key vs. certificate
> --------------------------
>
> In your introduction (and in the mail above), you refer to "certificate
> pinning" -- but i don't think there is anything out there that is
> "certificate pinning" -- HPKP is public key pinning, and it ignores the
> certificates that wrap any given public key.  So your tables should
> really refer to "main public key" and "backup public key", not "main
> certificate" or "backup certificate".
>

You are right. "Certificate pinning" is the more common term, but is it 
less precise.

>
> HPKP example workflow
> ---------------------
>
> Your HPKP timeline seems to assume that your "old backup certificate"
> can't be used as your "new main certificate" -- what makes you say this?

The longer you keep a keypair, the more likely it is to be compromised. 
So you may not want to keep a keypair in "cold storage" for a year, and 
then use it as a production cert for another year.

Depending on your setup, the risk may be much larger on the production 
server than on some offline storage, and then your proposed process 
makes perfect sense.

>
> I agree with you that HPKP end-entity pinning generally makes more sense
> (and is more useful at defending against malicious/incompetent CAs) than
> authority pinning.  But I'd expect an HPKP timeline using end-entity
> pinning to be more like:
>
> lower-case letters are public keys.  we presume that the site
> administrator has the corresponding secret keys backed up
> offsite/offline somewhere, and the associated certs and secret keys
> needed to operate the web site get deployed as needed.
>
> Initial deployment:
>
>
>   HPKP: { a, b }  Cert: A = X.509-wrapped(a)
>
> as A approaches expiry, we generate a new key c (storing its secret key
> offline), get a new cert made over b, and switch to:
>
>   HPKP: { b, c }  Cert: B = X.509-wrapped(b)
>
> As B approaches expiry, we do the same dance, generating d and making a
> cert over c:
>
>   HPKP: { c, d }  Cert: C = X.509-wrapped(c)
>
> and so on.
>
> Does this simpler cycle change your analysis of HPKP?
>
> I tend to think HPKP deployment has been slow because:
>
>   (a) the risk of bricking the site makes admins (justifiably) nervous
>
>   (b) having to have an additional offsite store (of your HPKP backup
>       secret key) to avoid site-bricking is a workflow that most admins
>       don't already have in place.
>
> But i don't think your proposal addresses these issues either (though
> the data stored offsite for (b) is slightly different between your
> proposal and HPKP).  Does it address them in some way that i'm missing?

One difference is that in HPKP, the data stored in (b) is 
security-critical, in that its compromise is just as bad as compromise 
of the site's regular secret key (you can use it to MITM all connections 
to the server). In my proposal the pinning secret is truly a "second 
factor". Its compromise is an issue only if you can *also* generate a 
fake certificate.

Another major difference is that my proposal avoids the manual 
management steps of HPKP (at least until we have ACME widely deployed). 
The pinning secret can be generated automatically when the server is 
started and rolled over periodically, with no human in the loop.

>
> Regards,
>
>       --dkg
>