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

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

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