Subject: [Lake] Poll for January lake wg virtual interim

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Dec 2019 21:17:55 +0000

Hiya,

At IETF106 we discussed having a virtual interim in January
to progress/close issues with the requirements document.
Mališa and I would like to try pick a date for that in the
next week.

Please fill in the poll [1] to indicate your availability.
All times in [1] are UTC - either 1500 or 1600 UTC. I guess
plan for a two-hour call, but we can decide later if we
need that much time. (I guess we'll propose a detailed
agenda early in Jan.)

Please fill in the poll before the end of Dec 16th so
we can pick a time before the holidays.

If none of those times work for you and you'd really like
to be at the meeting, feel free to reply here or to the
chairs alias ([email-masked]) so we can take that
into account.

Thanks,
S.

[1] https://dudle.inf.tu-dresden.de/dip-in-the-lake/

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Dec 2019 11:46:04 +0000

Reminder:

> we can pick a time before the holidays.

As of now, [1] it's looking like Thu Jan 16 1600 UTC is
winning. If that doesn't change by tomorrow I'll setup
a webex thing for then, and maybe a backup one for the
same time the following week, in case we run out of time
or just like chatting a lot:-)

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Dec 2019 20:38:22 +0000

Hiya,

Thanks all, I've scheduled meetings for:

- Jan 16th 1600 UTC, and
- Jan 23rd 1600 UTC.

I've requested 2 hour slots for both but we might
not need that long, we'll see closer to time.

Webex stuff below.

We can sort out agenda early in Jan and also figure
out if we only need one of those two meetings as
well, and which to keep if one's enough. It'd be
great if people can raise issues on the list (or
in github and then the list) between now and the
new year to help with agendising and figuring out
who really needs to be on the call.

Cheers,
S.

PS: In case someone wonders: The 23rd has one more
person who can attend, (10 vs. 11) but I figure it's
better to schedule both for the moment as chances are
someone's availability will change between now and
then in any case;-)

LAKE WG invites you to join this Webex meeting.

Lake virtual interim
Occurs every Thursday effective Thursday, January 16, 2020 until
Thursday, January 23, 2020 from 4:00 PM to 6:00 PM, (UTC+00:00) Dublin,
Edinburgh, Lisbon, London
4:00 pm  |  (UTC+00:00) Dublin, Edinburgh, Lisbon, London  |  2 hrs
Meeting number (access code): 645 835 024
Meeting password: C4j4PgDJ

When it's time, join the meeting.
https://ietf.webex.com/ietf/j.php?MTID=ma39f9f8ea114844f79e2c962c6efdd52

Add to Calendar
https://ietf.webex.com/ietf/j.php?MTID=m31715fa29e54db30d0d7ce118716a7c0

JOIN BY PHONE
1-650-479-3208 Call-in toll number (US/Canada)
Tap here to call (mobile phones only, hosts not supported):
tel:%2B1-650-479-3208,,*01*645835024%23%23*01*
1-877-668-4493 Call-in toll free number (US/Canada)
Tap here to call (mobile phones only, hosts not supported):
tel:1-877-668-4493,,*01*645835024%23%23*01*

Global call-in numbers
https://ietf.webex.com/ietf/globalcallin.php?MTID=mb28c544358b89779e001306dfd4fb04e

Toll-free calling restrictions
https://www.webex.com/pdf/tollfree_restrictions.pdf

JOIN FROM A VIDEO SYSTEM OR APPLICATION
Dial sip:[email-masked]
You can also dial 173.243.2.68 and enter your meeting number.

Join using Microsoft Lync or Microsoft Skype for Business
Dial sip:[email-masked]

Can't join the meeting?
https://collaborationhelp.cisco.com/article/WBX000029055

On 16/12/2019 11:46, Stephen Farrell wrote:
>> Please fill in the poll before the end of Dec 16th so we can pick a
>> time before the holidays.
> 
> As of now, [1] it's looking like Thu Jan 16 1600 UTC is winning. If
> that doesn't change by tomorrow I'll setup a webex thing for then,
> and maybe a backup one for the same time the following week, in case
> we run out of time or just like chatting a lot:-)
> 
> Cheers, S.
>

---

From: Göran Selander <[email-masked]>
Date: Fri, 20 Dec 2019 14:39:44 +0000

Hi,

To stimulate further discussion, here are some things that have been discussed and are addressed in latest version of the requirements draft [00].

1. Public key credentials
    
Both public key certificates and raw public keys need to be supported. Certificates are needed for generic zero-touch deployment. Raw public key is a significant message size optimization if the public key is already trusted. Two different public key types have been discussed: public signature keys and static Diffie-Hellmann keys. In the latter case signatures are replaced with MACs leading to a significant reduction of message size. Hence static DH keys are desirable to support.
    
Working assumption: support for signature based and static DH based authentication.

2. Mixed credentials
  
Mixed credentials, one party certificate and the other RPK, are motivated by a use case. Because of 1 we also need to support mixed types of public key credentials.

Working assumption: support for mixed signature and static DH based authentication.

3. PFS against compromise of which key material?
    
Examples:
    - protection against the loss of long-term keys at the initiator
    - protection against the loss of long-term keys at the responder
    - protection against the loss of ephemeral keys
    - protection against a bad RNG at initiator or responder
    
Working assumptions:
    - Protection against loss of long-term keys at initiator and responder.
    - Protection against bad RNG using randomness improvements such as draft-irtf-cfrg-randomness-improvements and analogously for symmetric keys

4. Number of round trips/messages and frame sizes
    
Mutual authentication requires at least 3 AKE messages. In radio technologies such as 6TiSCH and LoRaWAN performance is affected by AKE messages fitting into radio frames. The amount of data available for AKE messages is not fixed but depend on radio configuration such as scattering factors, data rates, number of hops etc.

    - The AKE could be spread out over 4 messages of smaller size (compare SIGMA-I and SIGMA-R). In principle, for certain AKE message sizes and radio configuration, the number of radio frames could be smaller with 4 AKE messages instead of 3. In practice, the number of radio frames may be either smaller or larger with 4 AKE messages instead of 3. 

    - With 3 AKE messages, the OSCORE request may be sent together with AKE message 3 resulting in 1 round trip before sending encrypted traffic data. If the AKE has 4 messages, then the protocol is never 1 RTT before traffic data, which increases the time for completing the protocol.
    
    - Experience from IKE shows that 4 messages are preferred for unreliable transport such as UDP. For LAKE, however, we assume transport over CoAP or other reliable transport.
    
Working assumption: The AKE shall have 3 messages.

5. Number of round trips/messages and identity protection
    
What identifying information shall be protected against what adversaries? As much as possible of the identifying information should be protected, but protecting all identifying information has impact on the properties, in particular number of messages/round trips.
    
    - Encrypting PSK identity with DH shared secret protects against passive network adversaries, but does not allow authentication of responder within 3 messages
    
    - Encrypting crypto algorithms does not allow negotiation of cipher suite within 3 messages
    
   - Encryption of connection identifier only works in asymmetric case and does not results in arbitrarily short identifiers
    
 Working assumption: The following data need not be encrypted:
    - PSK identifier
    - cipher suite
    - connection identifier

6. Application data
    
Applications may want to transport application data within the AKE to reduce round trips and number of messages. 

Working assumptions: 
   - The protection properties of the application data provided by the AKE depends on which protocol message (see Section 2.6 of [00])
   - The application data must not violate the AKE security properties. The assumptions on the application data needs to be detailed by the specification.

7. PAKE support
    
LAKE is focused on the setting of low latency, large number of devices, automated deployment, e.g. industrial IoT. The use of passwords has not been requested in this context.
    
Working assumption: PAKEs are out of scope for this version

8. PQC support 
    
There are currently no standardized PQC key exchange algorithms.
  
Working assumption: PQC is out of scope for this version

9. Selfie attack
    
The protocol is assumed to be two-party PSK, i.e. need not protect against attacks when more than two parties share keys.

Working assumption: The AKE need to protect against reflection attacks but need not protect against attacks when more than two parties legitimately share keys.

10. Extensibility
    
By supporting COSE, the AKE supports new algorithms, new certificate formats, ways to identify credentials, etc. The AKE may need to support new AKE methods, e.g. to later add PAKE support. Since simplicity is one objective with this work, care needs to be taken to avoid extensions working against this.

11. Support for different MACs in AKE and OSCORE
    
Longer MAC length for AKE than OSCORE may give better security properties.
    
Working assumption: The AKE shall support different AEAD/MAC algorithms for OSCORE and AKE

[00] https://tools.ietf.org/html/draft-ietf-lake-reqs-00

On 2019-12-17, 21:38, "Lake on behalf of Stephen Farrell" <[email-masked] on behalf of [email-masked]> wrote:

    Hiya,

    - Jan 16th 1600 UTC, and
    - Jan 23rd 1600 UTC.

    Webex stuff below.

    Cheers,
    S.

    Lake virtual interim

    
    Add to Calendar

    
    JOIN BY PHONE
    
    Global call-in numbers

    Can't join the meeting?

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 28 Dec 2019 09:32:14 -0800

Goran

Thanks for posting this. Some thoughts below.

> Both public key certificates and raw public keys need to be
> supported. Certificates are needed for generic zero-touch
> deployment. Raw public key is a significant message size optimization
> if the public key is already trusted. Two different public key types
> have been discussed: public signature keys and static Diffie-Hellmann
> keys. In the latter case signatures are replaced with MACs leading to
> a significant reduction of message size. Hence static DH keys are
> desirable to support.
>

Yes, I think I agree with this, but as soon as you introduce
this much flexibility, we have to ask whether it's negotiable
or whether you just assume that the RP will support whatever
the AP wants to offer. My sense is that negotiable is actually
required in at least some cases, but maybe others feel
differently.

> 2. Mixed credentials
>
> Mixed credentials, one party certificate and the other RPK, are
> motivated by a use case. Because of 1 we also need to support mixed
> types of public key credentials.
>

Agreed.

>     - Protection against bad RNG using randomness improvements such as
>       draft-irtf-cfrg-randomness-improvements and analogously for
>       symmetric keys

Agreed.

> Mutual authentication requires at least 3 AKE messages. In radio
> technologies such as 6TiSCH and LoRaWAN performance is affected by AKE
> messages fitting into radio frames. The amount of data available for
> AKE messages is not fixed but depend on radio configuration such as
> scattering factors, data rates, number of hops etc.
>
>     - The AKE could be spread out over 4 messages of smaller size
>       (compare SIGMA-I and SIGMA-R). In principle, for certain AKE
>       message sizes and radio configuration, the number of radio
>       frames could be smaller with 4 AKE messages instead of 3. In
>       practice, the number of radio frames may be either smaller or
>       larger with 4 AKE messages instead of 3.
>
>     - With 3 AKE messages, the OSCORE request may be sent together
>       with AKE message 3 resulting in 1 round trip before sending
>       encrypted traffic data. If the AKE has 4 messages, then the
>       protocol is never 1 RTT before traffic data, which increases the
>       time for completing the protocol.
>
>     - Experience from IKE shows that 4 messages are preferred for
>       unreliable transport such as UDP. For LAKE, however, we assume
>       transport over CoAP or other reliable transport.
>

It's probably useful to distinguish *messages* from *flights*. I agree
that we want three flights, but it seems clear that for some radio
technologies, it's not possible to get a full signature-based
exchange in three frames, so there needs to be fragmentation
somewhere. The question then becomes where that fragmentation
should happen and whether the AKE should be aware of it. That
seems like a more complicated question, especially with very
small frame sizes.

> What identifying information shall be protected against what
> adversaries? As much as possible of the identifying information should
> be protected, but protecting all identifying information has impact on
> the properties, in particular number of messages/round trips.
>
>     - Encrypting PSK identity with DH shared secret protects against
>       passive network adversaries, but does not allow authentication
>       of responder within 3 messages
>
>    - Encryption of connection identifier only works in asymmetric case
>      and does not results in arbitrarily short identifiers
>

Agreed.

> 6. Application data
>
> Applications may want to transport application data within the AKE to
> reduce round trips and number of messages.
>
> Working assumptions:
>    - The protection properties of the application data provided by the
>      AKE depends on which protocol message (see Section 2.6 of [00])
>
>    - The application data must not violate the AKE security
>      properties. The assumptions on the application data needs to be
>      detailed by the specification.

Hmm.. Maybe. I think this gets back to the question of messages
versus flights. I agree that you want to be able to send application
messages in the same flight as AKE messages, but "within the AKE"
seems too strong, and would violate key separation.

> 7. PAKE support
>
> LAKE is focused on the setting of low latency, large number of
> devices, automated deployment, e.g. industrial IoT. The use of
> passwords has not been requested in this context.
>

Agreed.

> Working assumption: PQC is out of scope for this version

Well, sort of. It would be bad if we couldn't easily add PQC,
but I agree we don't need to standardize it now.

> 9. Selfie attack
>
> The protocol is assumed to be two-party PSK, i.e. need not protect
> against attacks when more than two parties share keys.
>
> Working assumption: The AKE need to protect against reflection attacks
> but need not protect against attacks when more than two parties
> legitimately share keys.

Agreed on the second point. I'm not yet sure if we need internal
anti-reflection mechanisms or just key role sepatation.

> 10. Extensibility
>
> By supporting COSE, the AKE supports new algorithms, new certificate
> formats, ways to identify credentials, etc. The AKE may need to
> support new AKE methods, e.g. to later add PAKE support. Since
> simplicity is one objective with this work, care needs to be taken to
> avoid extensions working against this.

I'm not sure I understand what this means in practice.

> algorithms for OSCORE and AKE

This seems unnecessarily concrete. I tend to think we want to uplevel
the question and ask what the security requirements for the AKE are as
compared to the transport (OSCORE). This pulls in questions of key
separation, strength of the handshake integrity check, etc., but
it's not limited to OSCORE MAC.

-Ekr

On Fri, Dec 20, 2019 at 6:39 AM Göran Selander <goran.selander=
[email-masked]> wrote:

> Hi,
>
> To stimulate further discussion, here are some things that have been
> discussed and are addressed in latest version of the requirements draft
> [00].
>
>
> Both public key certificates and raw public keys need to be supported.
> Certificates are needed for generic zero-touch deployment. Raw public key
> is a significant message size optimization if the public key is already
> trusted. Two different public key types have been discussed: public
> signature keys and static Diffie-Hellmann keys. In the latter case
> signatures are replaced with MACs leading to a significant reduction of
> message size. Hence static DH keys are desirable to support.
>
> Mixed credentials, one party certificate and the other RPK, are motivated
> by a use case. Because of 1 we also need to support mixed types of public
> key credentials.
>
>     - Protection against bad RNG using randomness improvements such as
> draft-irtf-cfrg-randomness-improvements and analogously for symmetric keys
>
>
> Mutual authentication requires at least 3 AKE messages. In radio
> technologies such as 6TiSCH and LoRaWAN performance is affected by AKE
> messages fitting into radio frames. The amount of data available for AKE
> messages is not fixed but depend on radio configuration such as scattering
> factors, data rates, number of hops etc.
>
>     - The AKE could be spread out over 4 messages of smaller size (compare
> SIGMA-I and SIGMA-R). In principle, for certain AKE message sizes and radio
> configuration, the number of radio frames could be smaller with 4 AKE
> messages instead of 3. In practice, the number of radio frames may be
> either smaller or larger with 4 AKE messages instead of 3.
>
>     - With 3 AKE messages, the OSCORE request may be sent together with
> AKE message 3 resulting in 1 round trip before sending encrypted traffic
> data. If the AKE has 4 messages, then the protocol is never 1 RTT before
> traffic data, which increases the time for completing the protocol.
>
>     - Experience from IKE shows that 4 messages are preferred for
> unreliable transport such as UDP. For LAKE, however, we assume transport
> over CoAP or other reliable transport.
>
> What identifying information shall be protected against what adversaries?
> As much as possible of the identifying information should be protected, but
> protecting all identifying information has impact on the properties, in
> particular number of messages/round trips.
>
>     - Encrypting PSK identity with DH shared secret protects against
> passive network adversaries, but does not allow authentication of responder
> within 3 messages
>
>    - Encryption of connection identifier only works in asymmetric case and
> does not results in arbitrarily short identifiers
>
> Applications may want to transport application data within the AKE to
> reduce round trips and number of messages.
>
> Working assumptions:
>    - The protection properties of the application data provided by the AKE
> depends on which protocol message (see Section 2.6 of [00])
>    - The application data must not violate the AKE security properties.
> The assumptions on the application data needs to be detailed by the
> specification.
>
>
>
> 7. PAKE support
>
> LAKE is focused on the setting of low latency, large number of devices,
> automated deployment, e.g. industrial IoT. The use of passwords has not
> been requested in this context.
>
> The protocol is assumed to be two-party PSK, i.e. need not protect against
> attacks when more than two parties share keys.
>
> Working assumption: The AKE need to protect against reflection attacks but
> need not protect against attacks when more than two parties legitimately
> share keys.
>
>
>
> 10. Extensibility
>
> By supporting COSE, the AKE supports new algorithms, new certificate
> formats, ways to identify credentials, etc. The AKE may need to support new
> AKE methods, e.g. to later add PAKE support. Since simplicity is one
> objective with this work, care needs to be taken to avoid extensions
> working against this.
>
>
> On 2019-12-17, 21:38, "Lake on behalf of Stephen Farrell" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
>     Hiya,
>
> --
> Lake mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lake
>