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. An Authenticator is built especially for each connection, and encrypted with the session key by the TLS client. The only other that can decrypt it is the TLS server. With the client DH key only known to TLS client and TLS server, only they can construct the DH shared secret. What remains is MITM on the server side. This is detected when the Finished messages are off (these have more bytes for TLS-KDH). 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? 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. 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. It might be an idea to add protected fields from the Authenticator though, such as the usec timestamp, seq-number, client name@realm. Ilari> - The ciphersuite list looks bad: 1) IDEA (bad idea), CBC Ilari> (don't use), apparent SHA-1 prf-hash (REALLY bad idea)[1][2]. Yes, this is a naive/initial list, I knew I would need to interact here to get it pruned. Thanks, your suggestions will be taken care of! 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. Thanks! -Rick _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
