Re: [Lake] draft-ietf-lake-reqs-02

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

Hi Hannes

From: Lake <[e-mail]> on behalf of Hannes Tschofenig <[e-mail]>
Date: Saturday, 21 March 2020 at 10:05
To: "[e-mail]" <[e-mail]>
Subject: [Lake] draft-ietf-lake-reqs-02

Hi all,

Given the WGLC I reviewed this document and below are a few comments.

The introduction lists of number of specifications that reference OSCORE.
I know that the authors are super keen in having those listed and hence I would
argue for only one change: The text on LwM2M  says
"
   *  OMA Specworks LwM2M version 1.1 [LwM2M] defines bindings to two
      challenging radio technologies where OSCORE will be deployed:
      LoRaWAN and NB-IoT.
"
Just because something is in a spec does not imply that it will get deployed (or
even widely implemented). The jury is still out and let's wait and see how
successful OSCORE will be for LwM2M.

GS: This statement is based on intents expressed by companies and there has already been trials, but it is  changed from “will be” to “is planned to” since this seems to be a sensitive point for you.

A remark regarding the following two paragraphs:

   OSCORE was
   tailored for use with lightweight primitives that are likely to be
   implemented in the device, specifically CoAP [RFC7252], CBOR
   [RFC7049] and COSE [RFC8152].

   The AKE shall
   specify how COSE can be reused for identification of credentials and
   algorithms of OSCORE and the AKE, as extension point for new schemes,
   and to avoid duplicated maintenance of crypto library.

In embedded crypto implementations there are typically several layers, namely
* the implementation of cryptographic algorithms (AES, SHA256, etc.)
* an encoding scheme for transmission over the wire (e.g. COSE, TLS Record Layer, X.509 certificates, etc.)
* the actual key exchange protocol

The different layers may be used by different components and different requirements may exist for them.
For example, the stage 1 bootloader may be implemented in ROM, may only use a signature verification function, and is probably optimized for code size and fast signature verification but does not care about RAM usage (because there is no other program running at that time). A device management solution, code that is running when the device is working under normal conditions, will have different requirements. Furthermore, the code for these two systems may actually be written by different parties and re-use & maintenance may actually be more complex than it looks like.

GS: The analogy to consider is with the handshake and the record protocol. Would you consider design a TLS handshake that doesn’t support the same algorithms as the TLS record protocol, have encryption algorithms in different IANA registers, different encodings etc.?

From our investigations the biggest code size impact is actually with the cryptographic algorithms. Hence, I disagree that there is a requirement for the AKE to use COSE. (I understand that OSCORE uses COSE but only requires a small sub-set of it. In general, it seems that everyone just implements a subset of COSE..) If I develop an AKE that is good for low end IoT devices but it does not use COSE why would that be a problem?
(Note that I have seen IoT devices implementing different CBOR parsers as well. The reason is the same why developers pick and choose certain COSE components.)

GS: See response to Richard on this topic.

I wonder how the following two paragraphs relate to each other. The first paragraph
appears to be saying that reliable transport cannot be assumed. The second
transport says that it has to be assumed.

   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].

   Moreover, the AKE must support transport over CoAP.  Since the AKE
   messages most commonly will be encapsulated in CoAP, the AKE must not
   duplicate functionality provided by CoAP, or at least not duplicate
   functionality in such a way that it adds extra costs in terms of code
   size, code maintenance, etc.  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, such as provided by the CoAP Echo option
   [I-D.ietf-core-echo-request-tag].

GS: The first paragraph is speaking of what may happen (or not happen) after the AKE is completed, exemplified with the use of the no-response option. This is on CoAP layer and not related to underlying transport. The second paragraph speaks of transport of AKE over CoAP, so from the point of view of the AKE the transport is reliable. Is there some confusion here?


You may need to indicate what exactly you mean by “CoAP” because CoAP is in
the meanwhile a long, long list of specifications adding pretty much every functionality
you can imagine.

GS: CoAP here refers to RFC7252, RFC7959, and draft-ietf-core-echo-request-tag. We clarified this.

Furthermore, I don’t see a problem of adding features to an AKE even if they are
available in CoAP or in a CoAP extension. The reason is that the AKE may therefore
be run on top of a wider range of underlying protocols. It may also make the AKE more
robust and easier to use for developers.

GS: Of course it is a problem adding functionality for the same reason as your previous statement about CoAP. Duplicating functionality generally has a cost, in terms of complexity etc., in this case to handle packet ordering, message duplication, message fragmentation, cookie-based denial of service mitigation etc. Since the AKE must be able to run on top of CoAP there is also the potential issue of such mechanisms in the AKE and the corresponding at CoAP layer interfering with each other resulting in bad performance, race conditions or other quirks.


Could you elaborate a bit more on this sentence? I am also wondering what the
AKE  design implications of the non-CoAP-based transport are?

>   The AKE may use other transport than CoAP.

GS: See response to Richard.

I don't think there is a good understanding in the industry about the reasons why companies deploying
IoT systems prefer one credential type over the other. Hence, I would omit this statement.

> PSKs are often used in a first deployment because of their perceived simplicity.

GS: It is not uncommon to hear that PSK is perceived as simple (which still may just be a perception), but since there is no reference provided “often” is replaced with “sometimes”.

You may want to make references here to justify the statement of the massive
breaches of PSK-based provisioning systems in IoT environments. (Not that
PKI-based systems have been free of problems either....)

> However, PSK-based provisioning has inherent weaknesses.  There has
>   been reports of massive breaches of PSK provisioning systems,


GS: The text speaks about weakness in PSK-based provisioning in general, not necessarily in IoT environments. If breaches of this kind can happen, then they can happen in particular to IoT environments. A reference is added.

I would delete the sentence below because
(a) many IoT devices have some form of user interface, and
(b) the lack of a user interface is not necessarily relevant to the need for
different credential provisioning schemes.

>  The common lack of a user interface in constrained devices leads to
>   various credential provisioning schemes.

GS: Done.

I think you are downplaying the importance of unlinkability with your statement
on identity protection for connection identifier. There has been a lot of work
in the TLS and the QUIC working groups on this topic.. Happy to provide details.

>   Other identifying information that needs to be transported in plain
>   text is cipher suites and connection identifiers.

GS: This part is rewritten and connection identifier is not included in the current text. Let’s return to this in the solution discussion.

I think you should also mention that the use of OSCORE and an AKE at the CoAP
level provides different privacy features than using the protection at a layer below.
This may be important in light of the development of QUIC (and consequently in TLS)
where a lot of attention was paid to offer confidentiality protection of information
like the FQDN/URL.

GS: A note added to the privacy considerations.

Regarding "Auxiliary Data": I don't think it is appropriate to refer to access tokens
as auxiliary data given that those, particularly when used as PoP token, are actually
closer to certificates or Kerberos tickets.

GS: This document defines the term “auxiliary data” (out of lack of better terms) as a particular message field in the AKE. I don’t see the problem with transporting, say, a reference token in the auxiliary data field of message 1. But the explicit mentioning of access token is not essential so is removed.

In the same section you are then talking about the idea of sending CSR messages.

I think those are very different use cases and the implications for the design of the AKA
should better be separated. To me it appears that the ability convey a CSR/Cert exchange
falls more under the category of "early data" (and could be very similar to sending
data along-side the exchange before the AKA has been finished) while the access token use
is an alternative certificate format.

GS: Sending CSR is a different example of using auxiliary data. We included an example of how these different cases relate.

Denial of Service: We have seen that developers have problems with using a denial of service
mechanism when it is not built into the AKA. Even with CoAP deployments developers ran into
problems with reflection attacks. In your design you push this DDoS mitigation outside the
AKA and I think that's a bad design approach because application developers will get it wrong
(from what we know so far).

GS: If you are using CoAP, you need to use available DoS mitigation techniques even if not using an AKE. So, indeed, we need to help developers use the available tools. Unfortunately, just pointing at the security protocol may lead to a false sense of security. People generally believed that using CoAP with DTLS solved all potential issues which turned out to not be correct [draft-ietf-core-echo-request-tag].


Ekr talked about the performance aspects already and this has been fuzzy all along.
I would like to understand whether there are "hard bounds" or whether this is just something
in the line of "We would like to have an AKE with all the features of TLS but with a few bytes less
overhead".

GS:  Have a look at the updated section 2.10.4. I’m afraid that just a few bytes off TLS wouldn’t make much of a difference. But it is possible for an AKE to be significantly more compact:
https://tools.ietf.org/html/draft-ietf-lwig-security-protocol-comparison-04#section-2.1


Out of curiosity, I am wondering which features of the TLS protocol have not yet been covered in
form of requirements.

For example, I am not seeing functionality like:
 * OCSP stapling, indication with CAs a client supports,
 * post handshake client authentication,
* ticket-based resumption,
* the ability to use server-side authentication only (with client side authentication happening later)

GS: None of these have been requested. Let’s return to those questions in the solution phase.

Göran