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

[Daniel Kahn Gillmor <[e-mail]>]

On Mon 2015-10-12 09:18:17 -0400, Yaron Sheffer wrote:
> 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.

i'm not up-to-speed yet either, and am unlikely to be able to get to
this soon, sorry!

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

hm, i'm not convinced of this tradeoff in general -- in today's
"cloud-y" age, backing up to disk rather than keeping in RAM might
trigger writes to data storage that's owned by yet another entity.  This
means you have the potential for traffic decryption not only to those
who can access your CPU and RAM, but those who run your storage backend.

Even worse, if the pinning secret is derived from the session resumption
master secret as recommended in section 4.2, then the temptation will be
to store the session resumption master secret to disk, which puts the
forward secrecy of resumed sessions at risk.  If admins don't persist
the resumption master secret, but persist only the derived secret, then
there are two modes of operation: one running from the derived secret,
and one running from the backup secret, which sounds messy.

Perhaps some implementation guidance is warranted here?  

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

TLS servers themselves should not be able to track a TLS client in the
event that the client decides to not be tracked.  For example, a client
could refuse to initiate session resumption, and could offer a
standardized, common TLS Client Hello.

Maybe privacy from a pinned-ticket server can be achieved by a client by
simply never sending the ticket pinning extension, or by never sending
it on subsequent connections?  this would come at the cost of losing the
ability to detect when a server's identity gets swapped out, of course.
It's not a particularly satisfying tradeoff.

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

fwiw, "certificate pinning" is also used in
https://tools.ietf.org/html/rfc6125#page-11 to describe what browsers
often call a "security exception" -- a non-validating certificate that
the user explicitly decides to allow for a given site.  this kind of
additional grant is the *opposite* of the additional restriction you're
describing.  better to stick to "public key pinning", which has no such
connotations.

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

yes, i intended the proposal to be for an admin who has access to
offline storage (though even an encrypted thumb drive locked in a drawer
would do).

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

I'm not sure about this distinction.  No certificate has been issued for
the HPKP backup key until just before it is deployed.  So the attacker
has to get a certificate issued for that secret key anyway, right?

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

Since you'd still need to persist the secret to disk in some reliable
way that handles rotation, backup, etc. safely if you don't want to risk
bricking the site, I think you're saying that hypothetical software
stack X has a better chance at successful implementation and deployment
than hypothetical software stack Y.  ;)

Thanks for proposing this, Yaron.

       --dkg