[noise] Resumption PSKs

[Trevor Perrin]

On Mon, May 23, 2016 at 12:21 PM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
> 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.

It avoids the cost of deriving and keeping that extra key in memory,
if it turns out not to be needed.


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

Could be either.

Replacing them gets better forward secrecy, obviously.  Also, you're
probably sending the session ID or session ticket in the clear, so
replacing that makes the connections less linkable.


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

That's the alternative, but that means keeping the extra key around in
case you need it later, instead of just creating it on-demand.


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

Not quite - compromising the resumption key doesn't reveal the
original transport key, it just reveals some ciphertext from the
transport key - so no harm.

Compromising the transport key compromises any resumption keys derived
from it.  But if someone has compromised the endpoint they'll probably
get the resumption key in either case.  If the cipher is bad enough to
break with cryptanalysis, then resuming the session with the same
cipher is probably not going to help.


Trevor