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 <tls-boun...@ietf.org> on behalf of Dan Brown <danibr...@blackberry.com> Date: Thursday, October 26, 2017 at 13:11 To: Tony Putman <tony.put...@dyson.com>, "tls@ietf.org" <tls@ietf.org> 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:tls-boun...@ietf.org] On Behalf Of Tony Putman Sent: Thursday, October 26, 2017 11:03 AM To: tls@ietf.org 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
