On Mon, Jul 10, 2017 at 08:01:32PM +0300, Yoav Nir wrote: > > On 10 Jul 2017, at 17:16, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > >> 2. this proposal offers > >> significantly better security properties than current practice > >> (central distribution of static RSA keys) > > > > I fail to see any relevant difference in security properties > > between those two, never mind a significant improvement. > > I can see one way in which it is worse. > > With static RSA keys, you can configure the server to use only PFS > ciphesuites (ECDHE-RSA or DHE-RSA). If you want to enable the non-FS, > you need to switch to RSA ciphersuites, and that would be obvious to > any client. In fact, I think today a server would stick out if it > only supported RSA ciphersuites. > > There is no way to know that a server is doing what it says in the > draft. It’s completely opaque to the client. > > However, in both cases the server does get FS. As long as the server > has not enabled RSA ciphersuites or exportable private key shares, any > recorded TLS stream is safe even if the attacker later gets the > private key.
Well, a client could observe reuse of server ECDHE public keys... And servers can always share session keys with an auditing system. There's no way a client could detect this. I don't think we need to have the client KNOW what the server is doing because... how the heck can the server prove it's not publishing the client's secrets?? The server simply cannot prove that it is adhering to any privacy policy. Brief reuse of server ECDHE public keys is an optimization. I _think_ it's a safe optimization, and it's safer the shorter the reuse period is -- and correspondingly less safe the longer the reuse period. But I would prefer that anyone wanting auditability just build that into their implementations as a proper audit capability. Yes, it's more complex to later decrypt sessions, but it also doesn't mess with the protocol in any way. That said, I wouldn't object to the proposal if it meant to be Informational. I don't see how a document that describes a possible a configuration (not protocol!) that is not relevant to the Internet should be a Standards-Track RFC, or BCP for that matter. Informational will do. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
