Subject: [Lake] Comments on draft-selander-lake-reqs-03

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Nov 2019 16:21:38 -0800

I have reviewed this document. While I think this is a good start,
I think quite a bit of work is required to flesh out the actual
requirements. The document does a good job of specifying what
one might call the "generic" crypto requirements (PFS, downgrade
resistance, KCI resistance, etc.) but when we get down to the
things that notionally make LAKE unique, it gets somewhat handwavy.

Specifically, if we look at the sumary of the requirements, we
see:

   o  The messages must be as small as reasonably achievable and fit
      into as few LoRaWAN packets and 6TiSCH frames as possible,
      optimally 1 for each message.

"as small as reasonably achievable" is not a standard we can
actually apply and if taken literally would imply that if we
are in IETF LC and we find out how to remove 1 byte, we have
to go back to the drawing board. Surely that's not what we mean.

The situation is further confused by "optimally 1 for each
message". Assuming that I understand this document correctly, LoRaWAN
has 51-byte packet size, and I do not believe that it is not possible
to fit *any* current 3-message signature-based AKE into 1 frame per
message with 128-bit security, as all such AKEs require at least one
signature and one key from each side, which adds up to 384 bits with
DH and ECDSA (perhaps somewhat better with something like BLS). As
Karthik points out, it's potentially possible to achieve this with RPK
authenticating with a static DH key, but that is a major restriction
that we would need to discuss.

In order to be useful, I think this document needs to have relatively
precise maximum sizes that are derived from both (1) what's known
to be cryptographically possible and (2) the technical characteristics
of the existing communications substrates. Otherwise, we're just in
an endless cycle of trying to make improvements that have minimal
to no impact (this is doubly true for improvements which do not push
us over a packet boundary).

COMMENTS
S 2.1.
>         from [HKDF] to signify not necessarily uniformly distributed
>         randomness.)
>
>      o  identifiers providing a hint to the receiver of what security
>         context to use when decrypting the message (OSCORE Sender IDs of
>         peer endpoints), arbitrarily short

"hint" is a confusing term here. Can you explain what this means?

S 2.1.
>         peer endpoints), arbitrarily short
>
>      o  COSE algorithms to use with OSCORE
>
>      Moreover, the AKE must support the same transport as OSCORE, in
>      particular any protocol where CoAP can be transported.  Since the AKE

This seems like it needs either a list or a description of what those
requirements are.

S 2.1.
>      o  COSE algorithms to use with OSCORE
>
>      Moreover, the AKE must support the same transport as OSCORE, in
>      particular any protocol where CoAP can be transported.  Since the AKE
>      messages most commonly will be encapsulated in CoAP, the AKE must not
>      duplicate functionality provided by CoAP.  It is therefore assumed

This requirement seems over-strong. The desire here is not to have
additional extra cost, but duplicated functionality isn't inherently a
problem. Similarly, the requirement to reuse COSE seems over-concrete.

S 2.1.
>      messages most commonly will be encapsulated in CoAP, the AKE must not
>      duplicate functionality provided by CoAP.  It is therefore assumed
>      that the AKE is being transported in a protocol that provides
>      reliable transport, that can preserve packet ordering and handle
>      message duplication, that can perform fragmentation and protect
>      against denial of service attacks.

It's been a while, so I don't remember what CoAP's anti-DoS measures
are. Can you elaborate?

S 2.2.
>      However, PSK-based provisioning has inherent weaknesses.  There has
>      been reports of massive breaches of PSK provisioning systems, and as
>      many systems use PSKs without perfect forward secrecy (PFS) they are
>      vulnerable to passive pervasive monitoring.  The security of these
>      systems can be improved by adding PFS through an AKE authenticated by
>      the provisioned PSK.

Is the requirement here to have PSK + mandatory PFS or to have a PSK-
only mode?

S 2.2.
>      Bandwidth is a scarce resource in constrained-node networks.  To
>      minimize the bandwidth consumption it is therefore desirable to
>      support transporting the certificates by reference rather than by
>      value.  Considering the wide variety of deployments the AKE must
>      support different schemes for transporting and identifying
>      credentials, see Section 2 of [I-D.ietf-cose-x509].

Is the requirement here to support the ones in that draft? Or is that
just exemplary? I would expect the second.

S 2.2.
>      various credential provisioning schemes.  The use of RPKs may be
>      appropriate for the authentication of the AKE initiator but not for
>      the AKE responder.  The AKE must support different credentials for
>      authentication in different directions of the AKE run, e.g.
>      certificate-based authentication for the initiating endpoint and RPK-
>      based authentication for the responding endpoint.

What about the combination of PSK and RPK/Cert?

S 2.3.
>      based authentication for the responding endpoint.
>
>   2.3.  Identity Protection
>
>      Transporting identities as part of the AKE run is a necessity in
>      order to provide strong mutual authentication.  In the case of

This is not technically correct. There are situations where each party
only connects to one other party and then you do not need to carry the
identity.

S 2.3.
>      authentication.  The AKE should allow the most sentive idenity to
>      recieve the strongest protection.  Note that encryption of the PSK
>      identifier is first possible in the third AKE message, which implies
>      that at least four protocol messages are required for authentication
>      of responder in case of symmetric key authentication (see
>      Section 2.5).

This text is kind of unclear, but the facts of the matter as I
understand them are that you can only protect the PSK-id against a
passive attacker. Do you disagree?

Second, I'm not quite sure why you say you can't protect the PSK
identifier until the third message? That seems to assume that it's the
initiator who selects the PSK, but that's not always true.

Finally,  I'd push on this PSK identity protection requirement. It
makes the design of any AKE much more difficult. Can you justify it
more strongly?

S 2.4.
>      Motivated by long deployment lifetimes, the AKE is required to
>      support crypto agility, including modularity of COSE crypto
>      algorithms and negotiation of preferred crypto algorithms for OSCORE
>      and the AKE.  The AKE should support negotiation of the all COSE
>      algorithms that OSCORE supports.  The AKE negotiation must be
>      protected against downgrade attacks.

1. It's worth sharpening what that requirement is. You obviously can't
protect against the weakest authentication algorithm.
2. Is Post-quantum a requirement?

S 2.5.
>      The AKE cannot rely on messages being exchanged in both directions
>      after the AKE has completed, because CoAP/OSCORE requests may not
>      have a response [RFC7967].  Furthermore, there is no assumption of
>      dependence between CoAP client/server and AKE initiator/responder
>      roles, and an OSCORE context may be used with CoAP client and server
>      roles interchanged as is done e.g. in [LwM2M].

I am having a bit of trouble following what the restriction provided
by the second graf here is. Is that liveness?

---

From: Göran Selander <[email-masked]>
Date: Wed, 20 Nov 2019 06:47:12 +0000

Hi Ekr,

Thanks for a good review. Responses from me inline, my co-authors may want to add or subtract.

From: Lake <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Date: Wednesday, 20 November 2019 at 01:22
To: "[email-masked]" <[email-masked]>
Subject: [Lake] Comments on draft-selander-lake-reqs-03

GS: We can discuss if this is a “must” or a “should”, but the importance of small messages cannot be overestimated as it impacts all performance benchmarks. With fixed assumptions on spreading factors, data rates, number of hops etc., the available number of bytes of 6TiSCH and LoRaWAN determines the important message size thresholds. E.g. for a 6TiSCH 5-hop deep network under the assumptions made in the benchmark:

fragments_up = (size + 33) / 80
fragments_down = (size + 23) / 74

But changing assumptions on e.g. the number of hops leads to another threshold for fitting into 6tisch frames. Moreover NB-IoT has a per-byte impact. Additionally, we have requirements on e.g. encoding which are conflicting with “as small as possible”. At the end of the day the WG needs to make decisions about tradeoffs, the purpose of this draft is to support that decision. So there should be written something about how important it is to make messages small without requiring that unconditionally. Does anyone have a better proposal?

DH and ECDSA (perhaps somewhat better with something like BLS).

GS: Yes, this was discussed already at the interim in March. The missing clause here is “when possible”, but we can remove “optimally 1 for each message” as that is obvious, when possible.

As

GS: See above. The maximum size depends on the assumption on what radio protocol, data rates/scattering factors, number of hops. The benchmarks were based on common settings, not extreme. Smaller message will improve characteristics in general and for more constrained settings in particular.

COMMENTS
S 2.1.

GS: OK, this was an attempt to explain the non-requirement on uniqueness, but perhaps better simply refer to RFC 8613 and replace content of the bullet with “OSCORE Sender IDs of peer endpoints, arbitrarily short ”.

S 2.1.

GS: I believe we can restrict to CoAP: “Moreover, the AKE must support transport over CoAP.”

S 2.1.

GS:  Given a COSE implementation, the device should not also require another crypto library. This is not only about code size but about maintaining redundant code which is an extra cost. I agree that if there is no extra cost in code size, maintenance, etc. it is not a problem per se having duplicate functionality. We should make that more precise.

S 2.1.

GS: The main DoS feature is provided by the Echo option:
https://tools.ietf.org/html/draft-ietf-core-echo-request-tag

S 2.2.

GS: The requirement is PSK + mandatory. PSK-only is already supported by OSCORE.

S 2.2.

GS: The ones specified in draft-ietf-cose-x509 are what the IoT community has been requesting. This is yet another argument for reusing COSE as it makes those schemes available, and also new schemes as they appear. We will clarify that.

S 2.2.

GS: That has been discussed, but has not been considered a requirement.

S 2.3..

GS: I agree, the text is not correct. In general you would like to be able to transport an identifier though. We wil fix this

S 2.3.

GS: Yeah, this text appeared late – even after the spell check. Agree, protects only against passive attackers.

GS: Yes, in special cases the responder could know who it communicates with, which makes PSK identity redundant. In general the responder is not able to select PSK if it does not know who it is communicating with. That is probably what the text should say, we will revise this.

GS: This text on protection of PSK identifier is written to address a comment from Karthik who also described the protocol with protecting PSK identifier in the third message:
https://mailarchive.ietf.org/arch/msg/lake/zcS8QMHZ5jxuH3z2MrelKcXjPjo
This requirement and its tradeoffs are still in discussion. On the agenda for the WG meeting today.

S 2.4.

GS: The intention here is to protect against on-path attackers interfering in the selection of the common most preferred algorithm. How can it be formulated better?  Protection against bidding-down attacks?

GS: See my response to Karthik:
https://mailarchive.ietf.org/arch/msg/lake/ZYYWmS28fMyKKqjWDd2fjGfYeVg

S 2.5.
>      roles interchanged as is done e..g. in [LwM2M].

GS: For example, we cannot assume that AKE initiator coincides with the CoAP client and that a subsequent OSCORE request goes in one particular direction. This is perhaps less of a restriction and more of motivation why authentication has to be performed within the AKE.

Thanks,
Göran