Re: [Lake] [lake-wg/reqs] Placeholder for resumption (e743c87)

[Michael Richardson <[e-mail]>]

Thanks for the discussion.

{editing}

Eric Rescorla <[e-mail]> wrote:
    > Your question begs a more general question, which I think speaks to 'session
    >> resumption' situation, I think.
    >>
    >> And I guess there is distinction between:
    >> 1) avoiding expensive authentication, assuming a round for PFS.
    >> 2) avoiding expensive authentication, no PFS
    >> 3) re-establishing state after a restart, or a long sleep.
    >> (the responder might have expired the session data)
    >>
    > 4) doing an exchange to rekey for PFS
    >>

    > Actually, you don't need an exchange at all to get PFS: just ratchet the
    > keys forward as in TLS 1.3 KeyUpdate.

Ah, good point.


    >> (3) is different in a connectionless CoAP situation where there isn't a TCP
    >> session to maintain.  Do we include mechanism in AKE, integrating into
    >> OSCORE, such the responder initiates a session resume when it sees an
    >> OSCORE
    >> context that it does not recognize?

    > Good question. I had mostly been thinking of the setting in which the
    > sender knew it was reestablishing "connection" state (this can be true even
    > with UDP-type protocols as long as there is a concept of association). I
    > think this is what you mean with (1) and (2), right?

I think that this is going to be a common case that the initiator will not
know it has to resume.  A responder ("Resource Server"- RS in ACE
terminology) will have memory for N-crypto slots.
N will be a number somewhere between 4 and 64.
If there are <N clients, then all is well.

If there are more (likely), then the RS will practice some kind of LRU
algorithm on the slots.   It might be reasonable to partition the table into
frequent callers, and infrequent sensors.

For some sensors, they will do the key management once, will get an OSCORE
context and they will need to do the entire session setup/resumption in as
few as 1-RT.

I think that ACE already has some logic here, but I am not sufficiently
steeped in that art to name it. (I find I have to write code before I truly
know anything)
I think that LAKE will need to provide to rest of it.

{I finally watched the IETF106 LAKE WG recording today.
What time-travelling fun.  Especially at 2x playback speed.
I think that I had RATS at the same slot.}

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-