Re: [Lake] January lake wg virtual interim webex details

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

Thanks for the response. On request I made Github issues [1] of some of these points, more details inline.

[1] https://github.com/lake-wg/reqs/issues


From: Eric Rescorla <[e-mail]>
Date: Saturday, 11 January 2020 at 21:15
To: Göran Selander <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Stephen Farrell <[e-mail]>
Subject: Re: [Lake] January lake wg virtual interim webex details

Thanks for your response. I reformatted your message a bit to make the
quoting clearer and responded below.

> > > 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.
> >
> > 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.
> >
> >  GS: Agree about negotiation. Responder needs to be able to verify which method is being used.
> >
> > > 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.
> >
> > Agreed.
> >
> >
> >
> > > 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
> >
> > Agreed.
> >
> >
> > > 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.
> >
> > 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.
>
> GS: I didn’t understand the difference. Current terminology is in
> terms of “messages” (AKE units) and “frames”/”packets” (radio layer
> units). We want to minimize the number of radio layer units needed,
> but technology, regulations, configuration, etc. affect the size of
> the radio layer units. As you say, the AKE message may be fragmented
> by lower layers, but I don’t think we can require that the AKE layer
> to be aware or have any control of that.

Well, we might not *require* it, but it's quite possibly beneficial to
have it be aware of it.  To take an example: DTLS has an internal
fragmentation mechanism which allows for messages to be split over
multiple UDP datagrams. sThis has various advantages over IP
fragmentation, including (1) working in places where fragments are
blocked and (2) partial retransmission (DTLS 1.3 only). In some
discussions, I've heard it said that in general it's advantageous not
to rely on lower layer fragmentation. So, this seems like something we
should try to flesh out.

GS: I don’t know how to formulate a Github issue on this point but I added a terminology issue (#2). I agree that it may be beneficial to be aware of fragmentation, to the extent that is possible in specification time. We require support for transport over CoAP which has its own fragmentation, retransmission, etc., which the AKE is expected to reuse, but we also allow other transport.


> > > 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
> >
> > 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.
>
> GS: Right, the formulation “within the AKE” is not optimal, we should
> change that. What is meant is in the same message/flight as the AKE
> message, i.e. together with the AKE message. Now key separation
> impacts the message size, so there is a tradeoff to make here. It
> would be good to list what kind of key separation is actually
> important. Separation between flights/messages, separation between
> traffic data and session resumption, they both seems relevant. But it
> was not clear to us that the attack surface is expanded in any
> significant way with using a separate key for one flight and the kind
> of application data we expect to be used in this flight like an access
> token, authorization voucher, etc.  One interesting comparison is with
> certificates, would you require a separate key to encrypt the
> authentication certificate in the AKE?

No. What I mean here is that tou want to use separate keys to encrypt
the AKE messages (if they are encrypted as they are here) than the
keys used to encrypt the application messages. That allows you to
analyze the AKE in isolation and make statements about its properties
no matter how the application protocol behaves (for instance, if it
has a decryption oracle).

This is doubly important in situations where the record layer is
providing some of the security of the AKE (e.g., integrity of
negotiation and/or liveness), as opposed to just confidentiality for
the AKE messages.


GS: The point I was trying to make is that the kind of data we expect to transport in “Application Data”, e.g. an authorization voucher, could be similar to that contained in an authentication certificate, which are typically not protected with separate keys.  I’ve added a general issue (#4) about 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.
> > > > >
> > > > > Working assumption: PAKEs are out of scope for this version
> > > >
> > > > Agreed.
> >
> >
> > > 8. PQC support
> > >
> > > There are currently no standardized PQC key exchange algorithms.
> > >
> > > 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.
>
> GS: I think we agree on this. PQC signatures should be straightforward
> to add, but less clear what change a PQC key exchange would
> require. Also, that would probablynot be suitable for the most
> constrained setting.

I think it depends on what we end up with.

GS: I’ve added an issue (#5) on PQC requirement formulation.


> > > 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.
>
> GS: The intention with “the AKE need to protect against reflection
> attacks” was as a high level requirement without go into the solution
> space. Key role separation is one solution. Can we formulate the
> requirement better?

I'll give it some thought.

GS: I’ve added an issue (#6) on listing of specific attacks.


> > > 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.
>
> GS: This was an attempt to say that there is a trade-off between
> extensibility and complexity. Future extensions may have different
> objectives, but the current version of the protocol must not become
> heavy just to incorporate a generic extension mechanism. Other
> formulations are welcome.

I think I mostly agree with this, but it's not clear to me that
it's not worth paying *anything* for extensibility now (for instance
we are agreed we need extensibility of algorithms). This seems like
it's just going to be a judgement call, not a requirement.

GS: I’ve added an issue (#7) on extensibility vs. complexity



> > > 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
> >
> > 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.
>
> GS: This is a good discussion point for the interim. OSCORE needs
> AEAD, HKDF, Master Secret, Master Salt and Connection IDs. The
> potential relationship/independence between these and those of the AKE
> are relevant to document. Was this what you were thinking of? Göran

Maybe.

My primary point here (and I think Karthik has made this as well)
is that it's important that the AKE be covered by a full strength
integrity check. There are a number of ways to do this depending
on the overall architecture of the system.

GS: I’ve added an issue (#8) on strength of the handshake integrity check

Göran