Subject: Re: [TLS] Preshared Keypairs for (D)TLS 1.2

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 26 Oct 2017 17:28:07 +0000

MQV was not licensed as a part of the NSA ECC deal.

If I has a choice, I’d pick HMQV or FHMQV – with understanding that there are likely to be licensing issues. And I think those protocols would rule out use of EC keys on most of the currently available hardware tokens.

--

Regards,

Uri Blumenthal

From: TLS <[email-masked]> on behalf of Dan Brown <[email-masked]>
Date: Thursday, October 26, 2017 at 13:11
To: Tony Putman <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] Preshared Keypairs for (D)TLS 1.2

Hi Tony,

Perhaps (some variant of) Menezes—Qu—Vanstone MQV key agreement might work for your problem.  

There are some security analyses for variants MQV, e.g. HMQV, and it offers even better efficiency than triple-DH.  

The original MQV appears in a few standards (NIST SP 63a, IEEE 1363, ANSI X9.63, even SEC1, and was dropped from Suite B …).  I believe that some I-Ds were written on using MQV in TLS (or elsewhere in IETF), but they expired.

Best regards,

Dan

From: TLS [mailto:[email-masked]] On Behalf Of Tony Putman
Sent: Thursday, October 26, 2017 11:03 AM
To: [email-masked]
Subject: [TLS] Preshared Keypairs for (D)TLS 1.2

Hi all,

I've recently started working in the IoT space and wish to standardize 

our transport security by introducing the use of DTLS. It seems that the 

usual practice is to use PSK for mutual authentication, but I'm not 

happy with this solution. A breach of server security allows not only 

server impersonation, but also, due to the PSK symmetry, client 

impersonation.

We are already using static ECDH keys for authentication (at the 

application layer), so I looked for a way to make use of these in DTLS 

and came up with the following solution using (D)TLS 1.2:

Assume the client is provisioned with an Id, a corresponding private key 

'c_id' and a corresponding server public key 'S_id' (the server key may 

be different for each Id or it may be common across all clients); the 

server has a list of client public keys 'C_id' and corresponding server 

private key(s) 's_id'. This OOB pre-provisioning corresponds to that of 

a symmetric PSK.

The TLS 1.2 message exchange is identical to that for a TLS_(EC)DHE_PSK 

handshake as in RFC4279. This solution applies to both DH/DHE keys and 

to ECDH/ECDHE keys. The IoT solutions will typically use ECDH/ECDHE, so 

the following explanation focuses on the EC variant. The messages are:

    Client                                 Server

    ------                                 ------

    ClientHello         ----->

                                      ServerHello

                                ServerKeyExchange

                        <-----    ServerHelloDone

    ClientKeyExchange

    ChangeCipherSpec

    Finished            ----->

                                 ChangeCipherSpec

                        <-----           Finished

    Application Data    <---->   Application Data

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.

My questions to the list are:

=============================

1. Has anything similar to this been proposed before (I found nothing)?

2. Can anyone see a problem with this formulation?

3. Is there any interest in this (I would be happy to write an ID)?

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).

A constraint not made explicit above is that the (EC)DHE keys must use 

the same group/curve parameters as define the preshared keypairs. Since 

the ClientHello does not contain any client information, this means the 

server endpoint (e.g. as defined by SNI) can only support a single form 

of preshared keypair. This could be improved on in TLS 1.3.

I don't believe that this constraint is serious, because this method is 

designed to be used in the same scenarios as PSK; that is, where client 

and server have an OOB method of receiving authentication credentials 

from a common source. In this situation, the server is unlikely to be 

serving clients which use multiple types of preshared keypairs, though 

it does mean that if the keypair format is changed (e.g. strengthened) 

during the life of an IoT product then a new server endpoint will have 

to be defined for the upgraded products.

Additionally, this method is proposed to prevent the leaking of client 

credentials if the server is compromised. This means that the client 

private key must be high-entropy: this method is not suitable for keys 

derived from passwords or other low-entropy sources.

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. 

Regards,

Tony