« Return to Thread: draft-ray-tls-encrypted-handshake-00.txt

Re: draft-ray-tls-encrypted-handshake-00.txt

by Michael D'Errico :: Rate this Message:

| View in Thread

Yoav Nir wrote:
> On May 5, 2012, at 7:36 AM, Michael D'Errico wrote:
>
>> If you don't perform a second CCS prior to Finished, then there are
>> two problems I see:
>>
>>   - you can not use RSA key exchange anymore; how about PSK or SRP?
>
> That is a feature. With this draft, the server has to perform two asymmetric operations anyway: one for the key exchange (most likely D-H), and then it still has to do another one as proof of possession of the private key (or for SRP). The only advantage of RSA keying was that you got both in one operation, and that's gone anyway.

I don't see that as a feature.  Telling people that they can't do things
the way they've been doing them for a decade doesn't go over well.

Why throw away all of the TLS_RSA_xxx, TLS_PSK_xxx, TLS_SRP_xxx, (and
TLS_KRB5_xxx ?) cipher suites in one shot?  Wrapping them in anon DH
adds forward secrecy (attackers can't see the RSA encrypted secret, for
example).  People get to do things more or less the same as they've
always done, but get more security "for free".

>> Sending a second CCS solves both problems, and is not expensive either
>> in network overhead or running the PRF again.
>
> The PRF is not expensive. It's the operation used to generate the seed for the PRF that is expensive. It should be noted that this is a disadvantage of this proposal.

In cases where the second CCS would produce the same key material as the
first CCS (i.e. the master secret hasn't changed), an implementation can
optimize away the second one.

Mike
_______________________________________________
TLS mailing list
TLS@...
https://www.ietf.org/mailman/listinfo/tls

 « Return to Thread: draft-ray-tls-encrypted-handshake-00.txt