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

[Stephen Farrell <[e-mail]>]

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.