Isn't there a lower bar at the IETF for defining new cipher suites, as long as you're not seeking a "recommended" setting?
I think escrowing lower down keys / not MACing the messages beyond the handshake means that you lose authenticity and integrity of the message data, which is unattractive. How burdensome would the extra few bytes actually be, given that the alternative is substantially weaker security? Regards, Jonathan On Tue, 4 Dec 2018 at 16:19 Tony Arcieri <basc...@gmail.com> wrote: > On Sun, Dec 2, 2018 at 3:36 PM Nico Williams <n...@cryptonector.com> > wrote: > >> > I'm not a fan of systems like this, but I believe for security reasons >> they >> > should be designed in such a way that only the confidentiality of >> traffic >> > is impacted, and a "visibility" system isn't able to leverage the >> decrypted >> > traffic to resume decrypted sessions and thereby impersonate clients. >> >> Any key escrow system will have this property. Given the session keys >> (or a way to recover them) you can resume decrypted sessions. > > > Wouldn't escrowing only the client/server application traffic secrets > (instead of keys higher in the schedule) avoid this problem? These keys > would permit the one capability "visibility" appliance vendors allege to > care about: traffic decryption, without permitting others like session > resumption. > > The most obvious escrow design requiring no changes to the clients is to >> use a static eDH key on the server-side. The next most obvious such >> design is to have the server talk to the escrow agent. > > > It seems like with an out-of-band escrow agent, the traffic secrets could > be escrowed with no changes to TLS. > > -- > Tony Arcieri > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
