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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
