<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 24, 2016 at 3:55 AM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">TLS 1.3 is planning to store a value derived from the original master<br>
secret.  This is better, but it means the parties need to know at the<br>
time of handshake whether resumption is desired, and have to store<br>
this value for the lifetime of the initial connection.<br></blockquote><div><br></div>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.<br><br>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.<br></div><div class="gmail_quote"><div><br></div><div>Are resumption keys in your view single use or multiple use?  Do I get a new resumption key every session?  What about parallel sessions?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Because this is for low-end devices, we'd like to be more efficient,<br>
and only extract the resumption secret from the transport keys if and<br>
when it's needed.  For example:<br>
<br>
  resumption_secret = ENCRYPT(k, 2^64-1, "", zeros[32])[0..32]<br></blockquote><div><br></div><div>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.<br><br></div><div>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.<br><br>Different purpose, different key.<br></div><div><br></div><div></div>Cheers,<br><br></div><div class="gmail_quote">Rhys.<br><br></div></div></div>