Subject: [TLS] Semi-Static Diffie-Hellman Key Establishment for TLS 1.3

From: Eric Rescorla <[email-masked]>
Date: Mon, 5 Mar 2018 13:13:41 -0800

Hi folks,

Here's another entry in the DH-only pile.

I've just posted:
   draft-rescorla-tls13-semistatic-dh-00

This implements a semi-static DH exchange mostly borrowed from
OPTLS [0]. There are obviously connections with draft-putman, but
this is more oriented towards implementing a 1-RTT style
exchange where the client has no foreknowledge of the server's
capabilities (though it's extensible to 0-RTT) than towards
pre-distributed DH keys, and has less invasive changes to the
key schedule.

We'd like 10 minutes to discuss this in London.

Thanks,
-Ekr

[0] http://ieeexplore.ieee.org/abstract/document/7467348/

---

From: Christopher Wood <[email-masked]>
Date: Tue, 6 Mar 2018 20:26:21 -0500

Thanks for putting this together! I’m in favor of the mechanism and look forward to discussing it. Negotiating with signature_algorithms is a simple way to roll this out, it fits in cleanly with the key schedule, and the benefits outlined in the introduction (PRNG hardening, plausible deniability, etc.) seem worth the effort. Although the approach has its roots in OPTLS, we will certainly need to re-assess its impact on the handshake. (I know of some folks actively working on this.) We also need to spend more time thinking about the open issues — specifically, the story around early data encryption. This variant has the benefit of enabling early data with public key encryption, as opposed to (trackable) symmetric key encryption. It’s unclear to me whether or not we need to address the static share publication issue for this benefit.

Anyway, thanks again for the draft. I’ll read it carefully before London.

Best,
Chris

On Mar 5, 2018, 4:14 PM -0500, Eric Rescorla <[email-masked]>, wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Tony Putman <[email-masked]>
Date: Thu, 8 Mar 2018 17:41:05 +0000

Hi Ekr,

Firstly, thanks for this. My primary reason for putting together draft-putman was to propose a handshake exchange which only uses a single asymmetric algorithm. If this proposal is extended to include raw public keys (I think these are already supported, but not mentioned in the text) and an ECDH-based MAC for client authentication, then this satisfies my constraints.

As a single data point, I can state that some of the IoT products that I'm working with already use static ECDH keys for client authentication (though not within TLS).

Although OPTLS is able to use 0-RTT, I don't see how this capability could be used in this implementation, even if the client knows the server static key. Because SS is only included in the key schedule when the master secret is generated, the client_early_traffic_secret has no input secret. Conversely, if the SS is included in the key schedule as the PSK, then the certificate cannot be decrypted by a client which does not have the server static key.

My conclusion is that, although this is usable with pre-provisioned ECDH keys, this is not the main use case. The different use case results in fewer properties; in particular (as noted), a client static key is not included in the key schedule. This means application data sent from the server before the client finished message is received is sent to an unauthenticated client (this is not the case with either PSK auth or with draft-putman).

I think that this and draft-putman are not competing, but rather that they serve different use cases. They could be synergistic, such that this draft provides a mechanism for distributing a static key which could later be used in a draft-putman exchange; however, the natural continuation would be to use a resumption PSK, so this would only be useful if there were a long gap between session, which seems unlikely.

Regards,
Tony

From: TLS [mailto:[email-masked]] On Behalf Of Christopher Wood
Sent: 07 March 2018 01:26
To: <[email-masked]>; Eric Rescorla
Subject: Re: [TLS] Semi-Static Diffie-Hellman Key Establishment for TLS 1.3

Best,
Chris

On Mar 5, 2018, 4:14 PM -0500, Eric Rescorla <[email-masked]<mailto:[email-masked]>>, wrote:

Hi folks,

I've just posted:

Thanks,
-Ekr

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

Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury, SN16 0RP, UK.
This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please immediately and permanently delete it, and do not use, copy or disclose the information contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & training.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Mar 2018 15:24:53 -0800

On Thu, Mar 8, 2018 at 9:41 AM, Tony Putman <[email-masked]> wrote:

> Hi Ekr,
>
>
>
> Firstly, thanks for this. My primary reason for putting together
> draft-putman was to propose a handshake exchange which only uses a single
> asymmetric algorithm. If this proposal is extended to include raw public
> keys (I think these are already supported, but not mentioned in the text)
> and an ECDH-based MAC for client authentication, then this satisfies my
> constraints.
>

Yep, that should actually work just fine.

As a single data point, I can state that some of the IoT products that I'm
> working with already use static ECDH keys for client authentication (though
> not within TLS).
>

>
>
> Although OPTLS is able to use 0-RTT, I don't see how this capability could
> be used in this implementation, even if the client knows the server static
> key. Because SS is only included in the key schedule when the master secret
> is generated, the client_early_traffic_secret has no input secret.
> Conversely, if the SS is included in the key schedule as the PSK, then the
> certificate cannot be decrypted by a client which does not have the server
> static key.
>

Yes, I agree with you. OPTLS had a less linear key schedule. I think if you
wanted to do 0-RTT you would have to have it be a pretend PSK as you
suggest in your draft.

I think that this and draft-putman are not competing, but rather that they
> serve different use case

Agreed. It sounds like you have a set of use cases where you know how to
predistribute the server key? This is the part we found challenging int he
web context.

-Ekr

> s. They could be synergistic, such that this draft provides a mechanism
> for distributing a static key which could later be used in a draft-putman
> exchange; however, the natural continuation would be to use a resumption
> PSK, so this would only be useful if there were a long gap between session,
> which seems unlikely.
>
>
>
> Regards,
>
> Tony
>
>
>
> *From:* TLS [mailto:[email-masked]] *On Behalf Of *Christopher Wood
> *Sent:* 07 March 2018 01:26
> *To:* <[email-masked]>; Eric Rescorla
> *Subject:* Re: [TLS] Semi-Static Diffie-Hellman Key Establishment for TLS
> 1.3
>
>
>
> Thanks for putting this together! I’m in favor of the mechanism and look
> forward to discussing it. Negotiating with signature_algorithms is a simple
> way to roll this out, it fits in cleanly with the key schedule, and the
> benefits outlined in the introduction (PRNG hardening, plausible
> deniability, etc.) seem worth the effort. Although the approach has its
> roots in OPTLS, we will certainly need to re-assess its impact on the
> handshake. (I know of some folks actively working on this.) We also need to
> spend more time thinking about the open issues — specifically, the story
> around early data encryption. This variant has the benefit of enabling
> early data with public key encryption, as opposed to (trackable) symmetric
> key encryption. It’s unclear to me whether or not we need to address the
> static share publication issue for this benefit.
>
>
>
> This message is intended solely for the addressee and may contain
> confidential information. If you have received this message in error,
> please immediately and permanently delete it, and do not use, copy or
> disclose the information contained in this message or in any attachment.

---

From: Christopher Wood <[email-masked]>
Date: Thu, 8 Mar 2018 18:27:10 -0500

> > Yep, that should actually work just fine.

Agreed.

> > Yes, I agree with you. OPTLS had a less linear key schedule. I think if you wanted to do 0-RTT you would have to have it be a pretend PSK as you suggest in your draft.

That sounds right — the early application data key with OPTLS is `g^{sx}` instead of `psk`.

Best,
Chris

> >
> >
> > > I think that this and draft-putman are not competing, but rather that they serve different use case
> >
> > Agreed. It sounds like you have a set of use cases where you know how to predistribute the server key? This is the part we found challenging int he web context.
> >
> > -Ekr
> >
> >
> >
> >
> > > s. They could be synergistic, such that this draft provides a mechanism for distributing a static key which could later be used in a draft-putman exchange; however, the natural continuation would be to use a resumption PSK, so this would only be useful if there were a long gap between session, which seems unlikely.
> > >
> > > Regards,
> > > Tony
> > >