[noise] Resumption PSKs

[Rhys Weatherley]

On Tue, May 24, 2016 at 3:55 AM, Trevor Perrin <trevp at trevp.net> wrote:

> TLS 1.3 is planning to store a value derived from the original master
> secret.  This is better, but it means the parties need to know at the
> time of handshake whether resumption is desired, and have to store
> this value for the lifetime of the initial connection.
>

A low-end device will need to allocate some semi-permanent storage
regardless of whether the secret is created at the start or end of the
connection.  I'm not sure much is gained by deferring that decision to
later.

If the resumption key is one-time use only then I can perhaps see some
memory savings occurring, but not for a multiple-use resumption key.

Are resumption keys in your view single use or multiple use?  Do I get a
new resumption key every session?  What about parallel sessions?


> Because this is for low-end devices, we'd like to be more efficient,
> and only extract the resumption secret from the transport keys if and
> when it's needed.  For example:
>
>   resumption_secret = ENCRYPT(k, 2^64-1, "", zeros[32])[0..32]
>

It occurred to me the other day that resumption keys can also be generated
by extending the HKDF construction to output three values during Split().
The third is truncated to 32 bytes and used as the resumption PSK.  This
can also be extended to 4, 5, 6, etc values for additional information, or
ENCRYPT() can be used as a PRNG as you describe with the third output of
Split() as the PRNG key.

I'd probably feel more comfortable if the resumption key was not directly
related to the transport key.  A break in one reveals the other.  A
successful known-plaintext attack on one session reveals that transport
key, which then compromises the resumption key for follow-on sessions.
Goodbye forward secrecy.  With HKDF, the follow-on sessions remain safe.

Different purpose, different key.

Cheers,

Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20160524/e04152f2/attachment.html>