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

From: Tony Putman <[email-masked]>
Date: Thu, 26 Oct 2017 15:03:28 +0000

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 26 Oct 2017 18:21:29 +0300

> provides server authentication even if client keys are compromised.

So basically triple-DH.
 
> My questions to the list are:

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

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

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 26 Oct 2017 08:47:49 -0700

Interesting suggestion. As Ilari mentions, we did look at this a bit
previously, but ended up with a signature-based scheme for compat
reasons. I'd definitely be interested in seeing this fleshed out some
more and will try to take a look soon...

> authentication terms into Finished messages.

It's pretty straightforward to mix the static server DH share into the final
traffic keys (that last 0 input in the key schedule is kind of a placeholder
for that). As you say, the client's key is more difficult, but mixing into
the
Finished MAC would be relatively straightforward, though we might
need to mess with the key schedule a bit to make that work.

-Ekr

>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 26 Oct 2017 18:02:20 +0200

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

If you worry about server impersonation in TLS1.2 there are the RSA-PSK 
ciphersuites which require the server to utilize its private key in
RFC4279.

If you worry about client impersonation there is TLS with SRP
(RFC5054), which can also provide protection against server
impersonation on the SRP-RSA mode. The latter is only defined over FF,
i.e, there is no EC-based version of SRP defined for TLS.

regards,
Nikos

---

From: Tony Putman <[email-masked]>
Date: Thu, 26 Oct 2017 16:25:38 +0000

From: [email-masked] [mailto:[email-masked]]
> As with any new mode, it would require security analysis (which is not

Thanks for the keyword, Ilari: I've now found http://ieee-security.org/TC/SP2015/papers-archived/6949a232.pdf which talks about triple-DH. I'll read up some more on it and see if there's a reasonable security analysis.

Tony

---

From: Tony Putman <[email-masked]>
Date: Thu, 26 Oct 2017 16:41:12 +0000

From: Eric Rescorla [mailto:[email-masked]]
It's pretty straightforward to mix the static server DH share into the final
traffic keys (that last 0 input in the key schedule is kind of a placeholder
for that). As you say, the client's key is more difficult, but mixing into the
Finished MAC would be relatively straightforward, though we might
need to mess with the key schedule a bit to make that work.

I thought we would need to modify the key schedule in section 7.1, replacing the
PSK input at the start with the static share [c_id]S_id (or [s_id]C_id) and then replace
the (EC)DHE input lower down with the Triple-DH.

But I'd rather not get too sidetracked by the TLS 1.3 changes right now. I am in any
case not up to speed on all the changes and discussions around that.
--
Tony

---

From: Tony Putman <[email-masked]>
Date: Thu, 26 Oct 2017 16:45:38 +0000

From: Nikos Mavrogiannopoulos [mailto:[email-masked]]
> i.e, there is no EC-based version of SRP defined for TLS.

I worry most about client impersonation, because that is easy 
to scale if there is a server breach. I agree that the SRP-RSA method
defends against this, but I don't feel that it will make it into the IoT 
space.
-- 
Tony

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 26 Oct 2017 09:46:09 -0700

On Thu, Oct 26, 2017 at 9:41 AM, Tony Putman <[email-masked]> wrote:

> *From:* Eric Rescorla [mailto:[email-masked]]

That's one option.

But I'd rather not get too sidetracked by the TLS 1.3 changes right now. I
> am in any

Fair enough. I would say that we want an anonymous client mode to work
properly
(the same mode that QUIC Crypto uses)

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 26 Oct 2017 19:57:55 +0300

On Thu, Oct 26, 2017 at 04:25:38PM +0000, Tony Putman wrote:
> Thanks for the keyword, Ilari: I've now found
> http://ieee-security.org/TC/SP2015/papers-archived/6949a232.pdf which
> talks about triple-DH. I'll read up some more on it and see if there's
> a reasonable security analysis.

Sorry, I was unclear. I didn't mean security analysis of Triple DH in
general, but security analysis of triple DH as embedded to TLS.

-Ilari

---

From: Dan Brown <[email-masked]>
Date: Thu, 26 Oct 2017 17:10:25 +0000

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,

    Client                                 Server
    ------                                 ------
    ClientHello         ----->
                                      ServerHello
                                ServerKeyExchange
                        <-----    ServerHelloDone
    ClientKeyExchange
    ChangeCipherSpec
    Finished            ----->
                                 ChangeCipherSpec
                        <-----           Finished

Regards,
Tony

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 26 Oct 2017 20:10:22 +0300

> > the (EC)DHE input lower down with the Triple-DH.

Allowing PSK key slot to hold a keypair? However, that would only work
for server authentication, not client authentication, which would need
its own mechanisms. Which are rendered more interesting by being in the
last flight and thus not being able to affect server encryption keys.

Also, I would be real careful about how such thing would interact with
0-RTT. 0-RTT is difficult to analyze as is, you don't need unbound keys
to make it even more exciting.

-Ilari

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 26 Oct 2017 21:30:17 +0200

Hi Tony

thanks for sharing your thoughts.

It sounds a bit like you want to use public key crypto but without the
overhead of certificates.

If that's true then you might find https://tools.ietf.org/html/rfc7250
useful.

Ciao
Hannes

---

From: Christian Huitema <[email-masked]>
Date: Fri, 27 Oct 2017 07:36:58 -0700

> On Oct 26, 2017, at 9:57 AM, Ilari Liusvaara <[email-masked]> wrote:
> ...
> 

Not just security, but also privacy. The triple DH exposes the public keys of server and client in clear text during the initial exchange. That’s a big privacy issue!

— Christian Huitema

---

From: Tony Putman <[email-masked]>
Date: Mon, 30 Oct 2017 17:36:24 +0000

All,

Thanks for your many comments. I still feel that this would be a useful addition to the TLS authentication methods, and Eric expressed an interest in seeing this fleshed out more, so should my next step be to compose a draft document?

In response to the comments, I have searched the past draft documents and have found nothing on triple DH. It is used in the Signal protocol, which references some papers, but does not seem to have been taken up by the IETF anywhere. 

@Dan, thanks for the pointer to MQV variants. This seems to be more efficient and there have been a couple of TLS drafts on using this (last one in 2010). I could find no discussion of this in the list archives, which is odd, so I don't know why they did not progress. However, if there are licensing matters then I feel this would impede widespread implementation so I would not be interested in pursuing that path. 

@Hannes, I want to improve on PSK in the cheapest way possible. This means removing the overheads of certificates, but it also means removing the need for an ECDSA implementation in the IoT device. The associated protocol simplifications are also attractive for small devices. 

@Christian, I don't propose to expose the public keys, but the respective identities are exposed. As the protocol messages are identical to the ECDHE_PSK protocol, the privacy issues are likewise identical. Right now, I don't see a way around this in TLS 1.2. 

@Eric, I had not given any thought to anonymous client, as this was intended to improve on ECDHE_PSK. However, if you think that it's important then it seems straightforward to add, though additional security checks may be needed (I'll investigate). 

@Eric, @Ilari, if you think that I should also address the use of 3DH in TLS 1.3 then I'm happy to do so, but I would like to undertake it as a separate activity. I feel that there are too many differences to try to undertake it in a single document. 
-- 
Tony