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

[Göran Selander <[e-mail]>]

Hi,

So, are we happy with the current text in PR #12?

(Branch "resum", section 2.4:
https://lake-wg.github.io/reqs/resum/draft-ietf-lake-reqs.html#name-crypto-agility-and-security
)

As I read it, the text on generating keying material to avoid "the need for public key authentication in that handshake" captures both the aspect of computation and message overhead.

As John pointed out, there is an efficient solution at the OSCORE layer:
https://mailarchive.ietf.org/arch/msg/lake/5DAmN2c7cOXCUej-4XRHxa18MIQ

Michael: A mechanism for "responder initiates a session resume when it sees an OSCORE context that it does not recognize" is included in appendix B.2 of RFC 8613.



Göran


On 2020-02-11, 15:10, "Lake on behalf of Michael Richardson" <[e-mail] on behalf of [e-mail]> wrote:

    
    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]  https://protect2.fireeye.com/v1/url?k=f93c2eb3-a5b6fa72-f93c6e28-863d9bcb726f-39dd4b02ebbaaf29&q=1&e=8be049c4-db91-4323-9f15-e2897e32190d&u=http%3A%2F%2Fwww.sandelman.ca%2F        |   ruby on rails    [
    
    
    --
    Michael Richardson <[e-mail]>, Sandelman Software Works
     -= IPv6 IoT consulting =-