Re: [TLS] I-D: CipherSuites for Kerberos + DH

[Rick van Rein <[e-mail]>]

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