Re: [Lake] Forward Security with PSK-Only LAKE

[John Mattsson <[e-mail]>]

Hi Karthik,

This is a very good discussion to have. Agree that a lightweight FS mode without ECDHE is a good thing to have if it is significantly more lightweight than PSK-ECDHE and does not introduce synchronization problems.

Your suggestions for PSK-FS mode got me thinking if the AKE is the right layer to do this lightweight FS. Could it not be done more efficient on the OSCORE layer? E.g.

A                                              B
                    XXX-ECDHE
<---------------------------------------------->

A and B derive OSCORE session key K_eA1 and K_eB1 for OSCORE

A use K_eA1 for sequence number 0-(n-1)

A -> B: AEAD(K_eA1, msg_0,…)
A -> B: AEAD(K_eA1, msg_1,…)

A use K_eA2 = H(k_eA1) for sequence number n-(2n-1) and erases k_eA1 from memory

A -> B: AEAD(K_eA2, msg_n,…)
A -> B: AEAD(K_eA2, msg_n+1,…)

A use K_eA3 = H(k_eA2) for sequence number 2n-(3n-1) and erases k_eA2 from memory

A -> B: AEAD(K_eA3, msg_2n,…)
A -> B: AEAD(K_eA3, msg_2n+1,…)

etc....

Note that OSCORE already have a stateless PSK-FS mode defined in Appendix B.

>In practice, we may want devices to e.g.  bootstrap a PSK using SIG-ECDHE and then use
>PSK-FS for some period of time. After some period of time, we may want to throw away the
>PSK and do another SIG-ECDHE from scratch.

We may want to do that. We may also want to bootstrap a PSK using SIG-ECDHE and then use PSK-ECDHE for some period of time. These have different security properties. To discuss these topics further, I think we should discuss reasonable assumptions of what an attacker has access to in a constrained IoT environment and what kind of practical attacks we want to protect against.
- When an attacker gains physical access to a constrained IoT device, can he/she extract all the information or is long-term keys more protected than session keys?
- Does the attacker have access to all the traffic information? Many contrained IoT environments will be local.
- Is the attacker passive or active?

Cheers,
John

-----Original Message-----
From: Lake <[e-mail]> on behalf of Karthik Bhargavan <[e-mail]>
Date: Saturday, 18 January 2020 at 14:22
To: Benjamin Beurdouche <[e-mail]>
Cc: Eric Rescorla <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Lake] Forward Security with PSK-Only LAKE

    Yes, I take the point that we should be careful about security guarantees.
    
    Further expanding on Ekr’s comment, one can see that there is room for various AKE modes with different levels of guarantees.
    So far, we have mainly been thinking about PSK-ECDHE and SIG-ECDHE modes, since forward security was a core property.
    I think  we should also consider a PSK-FS mode that achieves forward security via key derivation.
    
    In practice, we may want devices to e.g.  bootstrap a PSK using SIG-ECDHE and then use PSK-FS for some period of time.
    After some period of time, we may want to throw away the PSK and do another SIG-ECDHE from scratch.
    
    -Karthik
    
    > On 18 Jan 2020, at 12:26, Benjamin Beurdouche <[e-mail]> wrote:
    > 
    > 
    >> So, if you tell me that LAKE will provide a mechanism <insert name> (e.g.FS) that enables us to recover secrecy from a
    >> passive compromise while most of the time using the PSK rotation for FS, I am willing to say it is ok.
    >> Otherwise, if there is no hope to introduce freshness via <insert mechanism> (e.g.FS) and that a compromised session will always
    >> remain compromised, I’ll maintain that we cannot claim this to be a secure AKE for protocols we’ll build on top…
    > 
    > 
    > (e.g. FS) -> (e.g. DH) obviously...
    > 
    
    -- 
    Lake mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/lake