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

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 21 Mar 2020 09:04:53 +0000

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.

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.

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

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

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.

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.

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.

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.

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,

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.

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.

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.

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.

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.

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

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

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)
Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.