Hello Ilara / Watson / TLS WG, Thanks again,
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. Now I see what you mean. Indeed, the master secret used in Finished does not take it into account in TLS 1.2, except under RFC 7627. > > > 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 Thanks, those are very good reasons indeed :) >> 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 > I think he means stuffing the key from kerberos as PSK input in > (EC)DHE-PSK ciphersuite. That is not going to work for this. PSK communicates untyped blobs, which makes the server take a leap of faith, and so it is pretty much limited to internal use. I'm working on getting Kerberos to crossover between realms, and TLS-KDH might become the killer app for that. The key-handling approach of PSK got me thinking though (pre-master = DH-shared-secret + preshared-key). It is a strikingly simple method to make (EC)DH orthogonal to the authentication exchange. It means all the DH-specifics can go... perhaps 75% of my text! >> 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. I am now preparing a new form, with ClientCertificate := krbTicket and CertificateVerify := krbAuthenticator. That seems to integrate really well with the rest of TLS, also for 1.3. * the Authenticator hashes all prior messages and stores them in "checksum", leading to the requested binding * the CertificateRequest can ask for various forms of authentication, even mixing Kerberos and X.509 * there will be Kerberos-only CipherSuites (mutual exclusion, so this authenticates the server) but it can also work with TLS_ECDHE_RSA_ et al * the TicketRequirementFlags will be a TLS Extension during ClientHello / ServerHello Rather different -- so a new text is coming up. -Rick _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
