Re: [CFRG] Comment on draft-irtf-cfrg-aead-limits-01

[John Mattsson <[e-mail]>]

Hi,

I think recommendations on re-keying probably have to discuss things like the key hierarchy in the security protocol and the security boundaries in the implementation. Re-keying can be done different levels.
-	Using the long-term authentication keys.
-	Inside the “record layer” like in TLS 1.3 and OSCORE
-	In the middle of these like TLS resumption, Child SA, or Signal Ratcheting.

Where to do re-keying also depends on the implementation, to protect against key leakage the re-keying needs to be done from keys stored behind some security boundary. Or from the “leaked key” themselves is DH/PFS is used. 

Stephen Farrell wrote:
> "Keys leak from devices. If you can re-key
> every year, do at least that. If every month, then re-key
> monthly. If more frequently then great, do it as often as
> you can afford. And in the limit, theory says you really
> have to re-key at least as often as section x.y says."

I would also like to see a document like that, but maybe AEAD limits is not the right place. If possible, I would say that you should to a Diffie-Hellman key exchange every day or every few hours, that is what a lot of governments recommend for IPsec.

Stephen Farrell wrote:
> I can some envisage developers reading text like this
> draft and concluding that they'll never hit the relevant
> limit (or more likely assuming that, as it means writing
> and testing less code) and never writing any code to
> trigger a re-key.

I think that is good point, I can envisage that too. Maybe the document could make it clear that the AEAD limits are just one reason to do re-keying and that re-keying should also be done to protect against key-leakage? I think key-leakage is likely a greater practical threats than the distinguishing and forgery attacks in the AEAD limits document.

Cheers,
John

-----Original Message-----
From: CFRG <[e-mail]> on behalf of Stephen Farrell <[e-mail]>
Date: Tuesday, 17 November 2020 at 01:43
To: Eric Rescorla <[e-mail]>
Cc: CFRG <[e-mail]>
Subject: Re: [CFRG] Comment on draft-irtf-cfrg-aead-limits-01


Hiya,

On 17/11/2020 00:38, Eric Rescorla wrote:
> What stops the TLS or QUIC stack from rekeying internally
> when it hits the limit without even notifying the developer.

The heat death of the (developer's local) universe? :-)

I can some envisage developers reading text like this
draft and concluding that they'll never hit the relevant
limit (or more likely assuming that, as it means writing
and testing less code) and never writing any code to
trigger a re-key.

Given the more likely risk is leakage rather than
exhausting the crypto-lifetime of a key (in at least
many cases), text addressing that may be useful.

Cheers,
S.