On Mon, Oct 12, 2015 at 6:53 PM, Benjamin Kaduk <bka...@akamai.com> wrote: > On 10/11/2015 08:46 AM, Watson Ladd wrote: >> On Sun, Oct 11, 2015 at 8:17 AM, Ilari Liusvaara >> <ilariliusva...@welho.com> wrote: >>> Some quick comments: >>> - The signed DH share does not look to be bound to anything (crypto >>> parameters negotiation, randoms, server key exchange, etc..). I can't >>> offhand say what that would lead to, but it looks even worse than >>> TLS ServerKeyExchange, which has known vulernabilities due to >>> lack of binding to things like ciphersuite. >>> - The ciphersuite list looks bad: 1) IDEA (bad idea), CBC >>> (don't use), apparent SHA-1 prf-hash (REALLY bad idea)[1][2]. >>> - Even use of DH is questionable. >> I would suggest piggybacking on the PSK mode, using the key Kerberos >> provides at both ends as the PSK key. This would address all of these >> issues in TLS 1.3 >> > > This would seem to require an application protocol doing some Kerberos > exchanges up front to establish the Kerberos session key before pivoting > into TLS-PSK in a STARTLS-esque fashion. If that's what the application > protocol would look like, it seems like there's no reason not to go > full-on GSSAPI with GSS_Pseudo_random to extract a PSK on both sides. > > This proposal (as complicated as it is, and I'm not sure that I'm > entirely comfortable with it yet) has the comparative advantage that the > application speaks TLS from the start, with the Kerberos messages > included in the TLS CKE. In that sense, at least, it is elegant.
It would (modulo some work by me, which is unlikely to get done) be possible to do this with the PSK-ECDH extension: have the first two messages contain information used to derive the PSK, which is used to authenticate in the same manner in the second round. The problem here is that TLS is not a catchall "Transport Layer Security" capable of taking any sort of desired key exchanges and producing a secure protocol from them, but instead requires a lot of annoying work to ensure the proofs go through. Mike Hamburg has presented Keccak based designs that do do this, and TLS 1.3 by default does a lot better with this. > > This proposal also includes a generic mechanism for the server to > indicate what service type and hostname should be used in constructing > the host-based service principal name for Kerberos, which is useful -- > the convention for that would otherwise have to be baked into the > application protocol. The considerations around client anonymity and a > protocol for the server to convey its expectations are also interesting, > though I'm not sure I would have put it in the -00 if it was my own > document. > > There are some nits in the Kerberos bits that I might mention over on > kitten. > > -Ben > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
