Re: [Lake] WGLC for draft-ietf-lake-reqs-01

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

Hi Richard

From: Lake <[e-mail]> on behalf of Richard Barnes <[e-mail]>
Date: Thursday, 19 March 2020 at 20:22
To: Michael Richardson <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [Lake] WGLC for draft-ietf-lake-reqs-01

Hi LAKE folks,

I have reviewed this document as part of the WGLC.  I do not believe it is ready yet.

Detailed notes follow, pointing out a bunch of inaccuracies and ambiguities, but the overriding problem is that this document doesn't provide a clear framework for evaluating protocols, which is the whole point of a requirements document.

Section 2.10 in particular is still quite hand-wavy, lacking even basic quantification for at least one link layer.  It seems like what we need to do a real evaluation (in addition to a bunch of more minor things noted below) is a set of scenarios, in terms of network environment and protocol functions, that we can evaluate different protocol candidates against.  Things like, "PSK mode with X25519/Ed25519/CCM8 over LoRa" or "RPK+PKI mode with P-256/GCM NB-IoT".


GS: First note that the primary reason for benchmarks/requirements was not to have a comparison between protocols:

https://mailarchive.ietf.org/arch/msg/lake/PkqiwDV6_s5iVVSCyL56Jy0wW4M/

But if you do want to evaluate protocol candidates, then the benchmarks provided should enable you to do that. The information was a bit spread out in 2.10 and is now compiled in 2.10.4. More below.


===

General - The document could be more clearly organized.  I would expect a structure something like:

* What the AKE can assume about the transport
* What it needs to provide for OSCORE
* What security properties it needs to provide
* What operational constraints it needs to meet

The content is largely there, but jumbled together and often insufficently specified (more details below).

GS: As the chairs urged us in the call to “keep the focus of your comments on the meat of the content” we propose we leave the structure as it is, as long as the content is largely there.

Section 1 - The mention of the Fairhair Alliance here seems unhelpful.  I thought we were agreed that the AKE we're discussing here would be 1-1, not group; the latter would call for quite different designs.  Assuming that agreement holds, the document should clearly reflect it.  This reference muddies the water.

GS: The references in this section were included to show the planned use of OSCORE, to identify the relevant technologies. Since OSCORE is designed to be efficient for securing group communication in constrained environments, e.g. building automation applications, it seemed relevant to mention an industry forum where that feature of OSCORE was acknowledged. After all - if you make a constrained implementation which supports groups, and 1-1 as a subset, you may want to use it also for 1-1. Meanwhile Fairhair Alliance merged with OCF, and last week there was a joint meeting OCF-IRTF/T2TRG presenting how (1-1) OSCORE is planned to be used in OCF. We replaced the reference to Fairhair Alliance with a reference to OCF instead.


Section 2.1, "The AKE shall specify how COSE can be reused for identification of credentials and algorithms of OSCORE and the AKE" - This requirement should be deleted.  For one thing, OSCORE doesn't have credentials.  And it's not clear that re-using COSE is the lightest-weight path.

GS: There are several reasons for reusing COSE for the AKE. OSCORE uses COSE crypto primitives, identification of algorithms for encryption, key derivation, etc.  COSE has a number of smart solutions used in constrained IoT, e.g. the COSE header parameters, CCM*, etc. Reuse of COSE implementation avoids duplicating implementations, representation of algorithms etc. for reduced footprint and maintenance. Both OSCORE and AKE uses an AEAD, key derivation, signature (in case of Group OSCORE, which is expected to be common in implementations). Having different constructs for using them creates unnecessary complexity that is bound to be a source of confusion and bugs in a combined AKE/OSCORE implementation. Imagine the TLS handshake and TLS record layer being different in this respect! Nevertheless, the text is now changed from “must” to “strongly recommend”.


Section 2.1, "the AKE must support transport over CoAP" - Does this mean that COAP framing needs to be included in the message size allocations?

GS: The AKE may support other transport (as noted below) but for the use cases where CoAP transport is required the CoAP message size needs be considered.


Section 2.1, "The AKE may use other transport than CoAP" - This section is a good start, but should be expanded to a normative list of things the AKE may depend on for transport.  These will be important design parameters for the AKE.  This would also be a good point to clarify that this is a two-party protocol and assign names to the parties (say, "client" and "server").

GS: The objective of this work is to produce a lightweight AKE for OSCORE, in which case the endpoint implements CoAP, and CoAP is expected to be the transport for the cases where OSCORE is used. This sentence is noting that other transports are not forbidden, but we don’t see the reason for detailing other transports at this stage as that is not required functionality.


Section 2.2 - You've laid out a massive number of possible scenarios here.  I count at least 17, by the time you count PSK plus all the combinations of (a) RPK vs. PKI (b) value vs. reference (c) both of the above for sender/receiver.  While this is possible (TLS does it for the most part), it might be helpful in an evaluation of candidates to understand which are the priority cases..

GS: Same remark as above about evaluation of candidates. The cases where the AKE must be performant are PSK and RPK, as stated in 2.10.4, in particular where RPK is pre-provisioned as PSK.

We are aware of some cases of mixed public key credentials where the constrained device provides a reference to its cert and gets RPK by value. We also know of one company who wants to transport RPK by value in an opportunistic setting. The constrained device seems to be Initiator in most cases. Perhaps others in the WG can provide other data points?


Section 2.3 - Do you really want to always require mutual authentication?  Are there not scenarios where it is acceptable for one party to be anonymous?

GS: In the use cases this work is focusing on at least one of the of the endpoints is a “thing” in the IoT. As far as we know no one has brought up a use case where the thing or the endpoint which the thing authenticates to is anonymous.

Section 2.3 - This section talks in terms of attacks, but doesn't say anything about actual authentication properties.  The latter would be helpful in supporting analyses of the protocol.

GS: Karthik has been active in the shaping this section for the purpose of supporting the analysis of the protocol. The different required methods are likely to have slightly different authentication properties, so may not be sufficient with one property. Those properties can come as an output of the analysis made during the design rather than being a requirement, since we anyway expect a discussion of the appropriate tradeoffs between performance and security.


Section 2.6, "the AKE is required to protect the identity of one of the peers against active attackers" - It's pretty clear from the constraints which peer is which in any practical protocol (server/passive, client/active, as in TLS 1.3).  You should just say that.

GS: Updated based on your and others’ comments.

Section 2.6, "Other identifying information that needs to be transported in plain text is cipher suites and connection identifiers" - This is the first and only mention of connection identifiers (!)  Section 2.1 talks about OSCORE sender IDs, but only as an *output* of the AKE, not something used within the AKE protocol.  I suspect this should just be dropped.

GS: The AKE needs identifiers in plain text to correlate messages. Since those identifiers are only discussed in this paragraph the term “connection identifier” is removed.


Section 2.6, "Encrypting crypto algorithms does not allow negotiation of cipher suite within 3 flights" - If you contrast this with the ESNI/ECHO work being done with TLS, it may or may not be true, depending on how you account for pre-configuration of server information.

GS: Removed based on your and others’ comments.

Section 2.7 - This section should be dropped or tightened up.  My preference would be to drop it, since the AKE's job is to negotiate keys, not carry application data.  If we're going to keep it, we need to be clear about what properties are expected, for example, by saying that the auxiliary data must be protected to the same level as AKE data in the same flight.

GS: Good formulation, we used that.


Section 2.7, "The auxiliary data must not violate the AKE security properties" - This is super vague.  Can you provide an example of what you mean?

GS: Auxiliary data can be used together with the AKE to build other security protocols, like in draft-selander-ace-ake-authz. Obviously this protocol needs to be analysed, for example that it does not introduce vulnerabilities into the underlying AKE. A stupid example is secret information carried in the AD.


Section 2.8, "Note that by supporting COSE" - The AKE is unspecified here.  It doesn't necessariliy support COSE.  This sentence should be struck.

GS: We rephrased this, but still mentions COSE since that is recommended to use.

Section 2.9 - Surprised to see this here, given that Section 2.1 says that DoS protection is provided by the transport.

GS: We agree that the first paragraph did not add much and removed that. But the second paragraph is still not covered elsewhere. Changed title to “availability”.



Section 2.10 - There's lots of information here, but not much of it actionable.  ISTM that in order to evaluate different protocols, we'll need to be able to predict how they perform in different network environments, on different platforms.  This section does not provide enough detail to support that analysis.

GS: Same remark as above about evaluation of candidates. Section 2.10.4 is now compiling information previously spread out in section 2.10 and should be actionable.