On Mon, Oct 12, 2015 at 07:14:05AM +0200, Rick van Rein wrote: > Hello, > > Thanks for the feedback. Responding to it: > > Ilari> - The signed DH share does not look to be bound to anything (crypto > Ilari> parameters negotiation, randoms, server key exchange, etc..). > > This is indeed easy to miss; it relies on Kerberos infra to deliver a > short-lived session key to only the proper TLS client and TLS server. > The ticket is part of this key delivery, and can travel over untrusted > networks. > > A alternative option to fighting MITM could be to include (a hash of) > the server-sent DH offer in the Authenticator. Only the Kerberos- > authenticated TLS server can decrypt it, making it detect MITM. Is > that considered benefial?
If I was to do things like the current proposal (as opposed to overloading DHE-PSK), I would put in hash of entiere client and server first flights. Otherwise things get "interesting" when considering tweaking handshake or replaying the encrypted CKE. And "interesting" in crypto is not good. > Ilari> I can't > Ilari> offhand say what that would lead to, but it looks even worse than > Ilari> TLS ServerKeyExchange, which has known vulernabilities due to > Ilari> lack of binding to things like ciphersuite. > > Have I taken away these concerns? Pointers to the known vulnerabilities > are welcome, of course. I'm not sure what you would like to bind to > CipherSuites. The SKE security issue (SKE isn't bound to the ciphersuite) has surfaced at least three times: 1) The DHE/ECDHE confusion. 2) FREAK 3) Logjam > Watson> I would suggest piggybacking on the PSK mode, using the key Kerberos > Watson> provides at both ends as the PSK key. This would address all of > these > Watson> issues in TLS 1.3 > > You mean to add the short-lived session key to the pre-master secret, right? > > I have a (weak) preference to leave that key behind the API to help > it being better protected. Also, I don't think it adds much to > the security explained above. I think he means stuffing the key from kerberos as PSK input in (EC)DHE-PSK ciphersuite. The security properties of that are much more straightforward than properties of present proposal. > Ilari> - Even use of DH is questionable. > > This is mod-exp DH, on account of its need for very large keys, right? > > I would love to take it out, and only leave ECDH; I put up mod-exp DH > initially because it might be desired for backward compatibility. If > I hear no warm-felt desire for mod-exp DH I will gladly remove it. Backward compatiblity? I don't think you need such thing with proposal like this. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
