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

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Feb 2020 13:18:44 +0100

Taking this to the list.

    ekr> This seems like generally good text, but I feel like perhaps there is
    ekr> another angle on it, specifically, whether it should be possible to do
    ekr> a new AKE exchange efficiently.

    > Perhaps
    > "The AKE shall provide a mechanism to use the output of one handshake
    > to optimize future handshakes, e.g., by generating keying material
    > which can be used to authenticate a future handshake, thus avoiding the
    > need for public key authentication in that handshake".

EKR, there is some subtly here.
The text speaks about avoiding public key authentication.
I'm unclear if that include DH exponentiation or not.

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

(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?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Feb 2020 05:11:50 -0800

> I'm unclear if that include DH exponentiation or not.

Yes, and.

Just to recap from the top, the protocol skeletons that seem most likely
for LAKE require multiple EC operations (assuming you are using EC). For
instance, mutually  authenticated SIGMA-I requires each side to do a
signature, a verification, and a DH key establishment. Obviously, this is
all kind of expensive, and so a resumption mechanism lets you bypass some
or all of it by bootstrapping the first handshake.

There are two primary options:

- Skip the entire handshake and just bootstrap off the key output by the
original handshake
- Do a DH exchange and use the original to authenticate that.

The first is obviously faster, but needs a mechanism like the one Karthik
proposes to provide PFS (and also needs you not to use an encrypted session
ticket type mechanism). The second provides PFS no matter how you manage
the PSK. It's also worth noting that a resumption mechanism is an easy path
to 0-RTT.

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

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

-Ekr

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Feb 2020 15:10:12 +0100

Thanks for the discussion.

{editing}

    > keys forward as in TLS 1.3 KeyUpdate.

Ah, good point.

    > 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  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Göran Selander <[email-masked]>
Date: Wed, 12 Feb 2020 10:22:50 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    {editing}

    
    Ah, good point.

    

    

    --
    ]               Never tell me the odds!                 | ipv6 mesh networks [
    ]   Michael Richardson, Sandelman Software Works        | network architect  [
    ]     [email-masked]  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    [