[Lake] Fwd: brief feedback on draft-selander-lake-reqs-00

[Rene Struik <[e-mail]>]

Dear colleagues:

I just had a look at the LAKE BoF "requirements" slides [1].

I have some reservations as to duty-cycle arguments with LoRaWAN 
("Benchmark 2") - see also my earlier comment of April 15, 2019 below 
(item #a). As to 6TiSCH ("Benchmark 3"), whose applications would 
include critical infrastructure, the cut-offs do not include any 
provision for certs, which easily tilt the numbers a lot. For serious 
applications one needs to consider a slghtly broader setting than a 
simple authenticated key agreement scheme.

Bottom line: while I do appreciate the perceived need to be "minimal" 
(whatever metric one measures this by: computational cost, communication 
size), etc., when making shopping lists, this may be at the detriment of 
operational security offered (see earlier comments (b) and (c) below, as 
well as algorithm agility requirement).

One question that occurred to me is how easy it would be to certify 
chipsets that implement crypto, but have data representation conversions 
that are not standard (e.g., if one uses EdDSA and does not guarantee 
the integrity of message encoding rules within the security boundary of 
the device under test, this may break the scheme right away).

Best regards, Rene

[1] 
https://datatracker.ietf.org/meeting/105/materials/slides-105-lake-lake-requirements-00.pdf

-------- Forwarded Message --------
Subject: 	brief feedback on draft-selander-lake-reqs-00
Date: 	Mon, 15 Apr 2019 14:38:33 -0400
From: 	Rene Struik <[e-mail]>
To: 	Göran Selander <[e-mail]>, [e-mail] 
<[e-mail]>



Dear Goran:

Some brief remarks on draft-selander-lake-reqs:
a) duty cycle (see Section 4.2.1 - LoRaWaN):
Duty cycle depends on context (e.g., duty cycle during Tx of a single 
frame is always 100%). According to ETSI [1], Section 5.4.1, duty cycle 
is relative to observation time window (Tobs) of 1 hour, where 
conformance ([1], Section 5.4.2), is defined relative to normal use 
during operational lifetime, where "the representative period shall be 
the most active one in normal use of the device. As a guide "Normal use" 
is considered as representing the behaviour of the device during 
transmission of 99 % of transmissions generated during its operational 
lifetime", and where "Procedures such as setup, commissioning and 
maintenance are not considered part of normal operation". This does 
suggest that inter-frame spacing is not necessarily 99 frames for each 
frame sent, as this section seems to claim. In fact, if key agreement is 
only done as part of network formation, it falls outside the duty cycle 
regulatory requirement.
b) few messages/few frames (Section 4.2 - Discussion):
The suggestion that a 3-message protocol is a requirement seems to be 
more an opinion/preference by the author, since lacking detailed 
technical justification. {If sending an additional frame causes "the 
probability of errors [to] increase exponentially", the medium access 
control layer seems to be unfit for use. Or, do you mean that if error 
probability is p, one gets prob no error in t frames equals (1-p)^t? If 
so, with small p with viable networks and small t, one definitely has 
(1-p)^t ~ 1 - t*p (i.e., almost linear degradation rather than the more 
dramatically sounding exponential).}
c) conflicting requirements (Section 4.1 - AKE for OSCORE vs. Section 
4.2 - Lightweight):
There are trade-offs between communication overhead and security 
properties, which generally should be explored in more detail before 
imposing a requirement. As an example, a strict requirement for PFS may 
necessitate increased communication overhead, since, e.g., a 
communication failure during an AKC-scheme with strict PFS may preclude 
reusing this keying material with a retry mechanism.
d) security considerations (Section 6):
Contrary to what is suggested, the document is mostly about "size" 
arguments and does not offer a definition of desired algorithmic and 
operational security properties for sensor networks.
e) protocol flavors (Section 2):
The suggested protocol options include authenticated key agreement using 
symmetric-key, raw public keys, and certified public keys. Another 
option, which may be worth exploring (even if discarded based on sound 
rationale) is a key agreement scheme where authentication is based on a 
short secret authentication string (password) or a short public 
authentic, yet not secret string that is provided by a user (see, e.g., 
[3]).
f) COSE algorithms (Section 4.1):
The algorithms in the current COSE specification (RFC 8152) may not have 
a rich enough set of primitives to instantiate the sought after 
authenticated key agreement protocol. As an example, to my 
understanding, COSE only facilitates use of static-ephemeral co-factor 
Diffie-Hellman. Thus, some changes to the COSE specification may be 
required if one wishes to use a protocol that uses co-factor 
Diffie-Hellman based on ephemeral key shares. (Of course, this may be 
easily facilitated, esp. if the underlying core crypto primitive is 
already defined).

These comments illustrate that some requirements are less clear-cut than 
as suggested in draft-selander-lake-reqs-00 and, that, in fact, there 
may be more to this than just a "smaller is always better" argument.

Rene

Ref:
[1] ETSI EN 300 220-1 V3.1.1 (2017-02);
[2] ETSI EN 300 220-2 V3.1.1 (2017-02);
[3] Authenticated Key Agreement - Using Short Authenticated Strings 
(Serge Vaudenay, Crypto 2005)

On 4/12/2019 12:20 PM, Göran Selander wrote:
> On request I compiled the requirements for the lightweight AKE for 
> OSCORE discussed on the list into a draft. This is not exactly the 
> formulation by the security ADs but the main requirements should be there.
>
> Göran
>
> On 2019-04-12, 16:20, "[e-mail]" 
> <[e-mail]> wrote:
>
> A new version of I-D, draft-selander-lake-reqs-00.txt
> has been successfully submitted by Göran Selander and posted to the
> IETF repository.
> Name: draft-selander-lake-reqs
> Revision: 00
> Title: Requirements for a Lightweight AKE for OSCORE.
> Document date: 2019-04-12
> Group: Individual Submission
> Pages: 7
> URL: https://www.ietf.org/internet-drafts/draft-selander-lake-reqs-00.txt
> Status: https://datatracker.ietf.org/doc/draft-selander-lake-reqs/
> Htmlized: https://tools.ietf.org/html/draft-selander-lake-reqs-00
> Htmlized: https://datatracker.ietf.org/doc/html/draft-selander-lake-reqs
> Abstract:
> This document contains the requirements for a lightweight
> authenticated key exchange protocol for OSCORE.
> Please note that it may take a couple of minutes from the time of 
> submission
> until the htmlized version and diff are available at tools.ietf.org.
> The IETF Secretariat
>
> _______________________________________________
> Secdispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdispatch


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]