On Thu, Oct 26, 2017 at 03:03:28PM +0000, Tony Putman wrote: > > The way this differs from TLS_ECDHE_PSK is only in the generation of > the premaster secret. Suppose the ECDHE keys are 'a' (private) and 'A' > (public) from the server; and 'b' (private) and 'B' (public) from the > client. Then the client and server form the premaster secret in a struct > with the following information (where [x]Y represents multiplication of > the point 'Y' by the scalar 'x'): > Client Premaster: [b]A || [c_id]A || [b]S_id > Server Premaster: [a]B || [a]C_id || [s_id]B > > The first term provides PFS even if both client and server static > private keys become known; the second term provides client > authentication even if server keys are compromised; and the third term > provides server authentication even if client keys are compromised.
So basically triple-DH. > My questions to the list are: > ============================= > 1. Has anything similar to this been proposed before (I found nothing)? Triple-DH is defined in some protocols. > 2. Can anyone see a problem with this formulation? As with any new mode, it would require security analysis (which is not exactly simple). > The reason that I advocate this for IoT devices over signature schemes > is that the code for ECDH will already have to be present if modern > key agreement methods with PFS are to be used. So this solution uses > fewer resources than ECDHE together with a signature scheme in terms of > code space and RAM, and improves execution speed (I believe ECDH is about > twice as fast as equivalent signature generation/checking). Also, fewer > messages are needed and the messages are smaller (even if using raw keys). I think the gap between the two in speed is smaller than that. The dominant factor in signing is fixed-base scalarmult and in verification double scalarmult (which can be optimized). Whereas with ECDH, it is fixed-base scalarmult and variable-base scalarmult. > Lastly, I have had a look at extending this to TLS 1.3 and it seems > pretty straightforward; however, there is no urgency and I feel we can > defer that to after the TLS 1.3 draft has been approved. I don't think this is straightforward to extend to TLS 1.3. There has been proposal which had mode similar to this, but the TLS 1.3 key exchange looks pretty different from it. Especially annoying would be that since TLS 1.3 is three-flight key exchange, the client authentication can not affect traffic keys. So presumably the best thing that could be archived is mixing the DH authentication terms into Finished messages. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
