Re: [Secdispatch] brief feedback on draft-selander-lake-reqs-00

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

Hi Rene,

Please find responses inline. 

On 2019-04-15, 20:39, "Rene Struik" <[e-mail]> wrote:

    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.

Two applications of EDHOC in the context of LoRaWAN were mentioned at the interim meeting. One is for the rekeying of LoRaWAN  AppKey, the other is for end-to-end security on application layer between device and cloud service, where LoRaWAN is the last hop. In both cases the message sizes over the LoRaWAN link are relevant for the performance. While the first case may be exempted, the second is independent of network formation. I will make this more clear in -01.

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

For NB-IoT, the performance characteristics are not sensitive to the distribution of content into frames, but the time until encrypted traffic data can be sent is highly dependent on the number of roundtrips for completing the protocol. Therefore as few roundtrips as possible is important. The error probability is related to properties of slotted Aloha used by 6TiSCH, but is not critical for the argument so instead of going into details I will remove it in -01.

    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.

I didn't really understand this comment, in particular the last sentence. OSCORE is not required to be deployed with PFS, but there are applications were PFS is needed and the increased communication overhead of an AKE is acceptable.

    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.

I will reformulate the sentence of this section in -01.

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

Other credentials may be added later in the process, the ones currently listed are believed to be the most relevant.

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

From a COSE point the EDHOC use of DH is Static-Static, but, as you remark, this can easily be added to COSE should that assumption change. 

    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.

The intent with this draft was not to write a very detailed requirements specification that one day will become an RFC. Its purpose was to meet a request to compile discussion spread out over different emails, including some general metrics which are expected to have a positive impact on the performance in common settings. 

Göran


    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]