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

[Eric Rescorla <[e-mail]>]

On Mon, Feb 10, 2020 at 8:17 AM Michael Richardson <[e-mail]>
wrote:

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

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.


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.


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

-Ekr