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

From: John Mattsson <[email-masked]>
Date: Mon, 16 Nov 2020 14:32:44 +0000

Hi,

The draft defines l as  "Length of each message (in blocks)" While https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf defines l as "input length in blocks"

I assume the definition in the draft should be "input length in blocks" and that the rewriting comes from TLS where A = "". It would also be good to clearly define what "input" (or "message") is, none of the terms are well-defined. Suggestion:

OLD    "Length of each message (in blocks)"
NEW   ""input length (plaintext + additional authenticated data) in blocks"

(I assume https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf means that "input" is P and A, i.e. not K and N).

Cheers,
John

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 17 Nov 2020 09:28:54 +1100

Thanks John,

We have planned to split the input length into two variables: one for the plaintext length, one for the AAD length.  This should help for those cases where the usage skews heavily toward one or the other and the bounds are substantially different based on that.

For instance, the CCM analysis counts plaintext as consuming 2 blocks and AAD as consuming 1.  For a protocol that mostly just authenticates, that might result in being able to send twice as many messages as an all encrypted protocol.  That's not a big deal, but then CCM bounds aren't exactly generous, so that might turn out to be useful.

On Tue, Nov 17, 2020, at 01:32, John Mattsson wrote:
> Hi,
> 
> The draft defines l as  "Length of each message (in blocks)" While 
> https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf defines l as "input 
> length in blocks"
> 
> I assume the definition in the draft should be "input length in blocks" 
> and that the rewriting comes from TLS where A = "". It would also be 
> good to clearly define what "input" (or "message") is, none of the 
> terms are well-defined. Suggestion:
> 
> _______________________________________________
> CFRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Nov 2020 00:09:48 +0000

Hiya,

I've a higher level question about this topic that came
up a bit in the LAKE WG session this morning (my time;-)
I'm not sure if this draft would be a good vehicle to
address this or not.

I'm unsure whether application developers using EDHOC
or cTLS or TLS would really make use of drafts such as
this to e.g. decide when/whether or not to re-key. ISTM
the text in this draft is more useful for authors of
other drafts (such as EDHOC etc.) when the want to write
security considerations.

Now, maybe it's fine to say that's enough for us to do,
but (assuming we can't automate re-keying) I do wonder
if all that's sufficiently understandable to a normal
developer or not? And if not, then I suspect the upshot
would be some keys never being changed and thus leaks and
attacks (not really due to AEAD limits mind, but more
due to the probability of a key leaking over time from
a borked or de-commissioned device).

So while this draft and similar are exercises well worth
doing, I suspect someone somewhere also needs to provide
some more prosaic (yet safe) rule-of-thumb guidance to
which developers might pay attention.

For example, I'd imagine developer-friendly text might say
something like "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."

Does anyone know of a draft that has text like that? Or
would it be good to add it to this one? (In the hope
that it'd percolate out via stackexchange or whatever
and eventually get to the right audience.)

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Nov 2020 16:19:41 -0800

On Mon, Nov 16, 2020 at 4:10 PM Stephen Farrell <[email-masked]>
wrote:

> developer or not?

I'm not following you here. This draft is about the lifetime of symmetric
keys, which you can automate.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Nov 2020 00:27:35 +0000

> keys, which you can automate.

"Can" - sure. But while I'm open to correction, I believe
lots of small embedded systems using TLS and the like, and
maybe still cookie and/or token generating chunks of code,
do not.

With TLS or similar, at the point where the developer's
code has decided it's time to re-key, then the HOWTO is
automated. But the decision to do the re-key isn't.

With cookies and tokens, doing the re-key is a local
matter, (and pretty obvious), but still has to be decided
upon.

Again, that might be better not in this draft but I think
it may be a bit of text we don't yet have.

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Nov 2020 16:38:09 -0800

> automated. But the decision to do the re-key isn't.

What stops the TLS or QUIC stack from rekeying internally
when it hits the limit without even notifying the developer.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Nov 2020 00:42:58 +0000

Hiya,

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

---

From: John Mattsson <[email-masked]>
Date: Tue, 17 Nov 2020 09:03:16 +0000

Splitting up the parameter l in that way sounds like an excellent idea! That makes the document applicable to RFC 5116 in general rather than just a special case of RFC 5116.

Cheers,
John

-----Original Message-----
From: CFRG <[email-masked]> on behalf of Martin Thomson <[email-masked]>
Date: Monday, 16 November 2020 at 23:29
To: "[email-masked]" <[email-masked]>
Subject: Re: [CFRG] Comment on draft-irtf-cfrg-aead-limits-01

Thanks John,

On Tue, Nov 17, 2020, at 01:32, John Mattsson wrote:
> https://protect2.fireeye.com/v1/url?k=4b68e622-14f3df66-4b68a6b9-861d41abace8-ca5386d0404249bd&q=1&e=fd208f4b-1d6f-42ac-9a1f-5b4b5afc427d&u=https%3A%2F%2Fwww.isg.rhul.ac.uk%2F%7Ekp%2FTLS-AEbounds.pdf defines l as "input 
> length in blocks"
> 
> (I assume https://protect2.fireeye.com/v1/url?k=9b80f671-c41bcf35-9b80b6ea-861d41abace8-f5e131f6d996e9f7&q=1&e=fd208f4b-1d6f-42ac-9a1f-5b4b5afc427d&u=https%3A%2F%2Fwww.isg.rhul.ac.uk%2F%7Ekp%2FTLS-AEbounds.pdf means that 
> "input" is P and A, i.e. not K and N).
> 
> Cheers,
> John
> 
> 
>   
> 
> 
> 
> https://protect2.fireeye.com/v1/url?k=99f44065-c66f7921-99f400fe-861d41abace8-6df16c72f07ebf97&q=1&e=fd208f4b-1d6f-42ac-9a1f-5b4b5afc427d&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg
>

_______________________________________________
CFRG mailing list
[email-masked]
https://protect2.fireeye.com/v1/url?k=500254a6-0f996de2-5002143d-861d41abace8-51f58f0c7a1ecfea&q=1&e=fd208f4b-1d6f-42ac-9a1f-5b4b5afc427d&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg

---

From: John Mattsson <[email-masked]>
Date: Tue, 17 Nov 2020 09:05:26 +0000

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

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.

> and testing less code) and never writing any code to

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 <[email-masked]> on behalf of Stephen Farrell <[email-masked]>
Date: Tuesday, 17 November 2020 at 01:43
To: Eric Rescorla <[email-masked]>
Cc: CFRG <[email-masked]>
Subject: Re: [CFRG] Comment on draft-irtf-cfrg-aead-limits-01

Hiya,

Cheers,
S.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 17 Nov 2020 22:03:43 +1100

> and testing less code) and never writing any code to

We have an action to cite RFC 8645, which does cover this topic.  Consider this a companion document to that one.

Maybe neither is pragmatic enough.  But this was always intended as a handbook for those people building protocols.  Less for those building implementations of those protocols.  This is too far removed from implementations to be useful at that level.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Nov 2020 14:25:09 +0000

Hiya,

On 17/11/2020 11:03, Martin Thomson 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.
> 
> We have an action to cite RFC 8645, which does cover this topic.
> Consider this a companion document to that one.
> 
> Maybe neither is pragmatic enough. 

Yeah, I'm thinking that may be the case.This and
8645 are both good and useful, just for other readers.

> But this was always intended as a
> handbook for those people building protocols.  Less for those
> building implementations of those protocols.  This is too far removed
> from implementations to be useful at that level.

That's fair. Maybe someone'll be inspired to write
about it by this thread;-)

Cheers,
S.

> 
> _______________________________________________ CFRG mailing list 
> [email-masked] https://www.irtf.org/mailman/listinfo/cfrg
>