Re: [Ace] (details on use case scenario?) Re: [Lwip] EDHOC standardization

Rene Struik <rstruik.ext@gmail.com> Mon, 18 March 2019 14:15 UTC

Return-Path: <rstruik.ext@gmail.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4BA12865E; Mon, 18 Mar 2019 07:15:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yP_sKXDo-Dys; Mon, 18 Mar 2019 07:15:34 -0700 (PDT)
Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A241812423B; Mon, 18 Mar 2019 07:15:34 -0700 (PDT)
Received: by mail-it1-x12d.google.com with SMTP id w18so20629100itj.4; Mon, 18 Mar 2019 07:15:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=7dQF10nA4DcBWsWq2WNrdG4CFJHiBcNY5kMHGDXDtrM=; b=soz0JiY//TsJlf769U5vogjpgu263kyrjwyLKYPEsFycJYc6kIn3kjUvtQ0MWevhHn oo9SUoxSHBF/8R4/ZiRaNdAGYFaLf85U5uBJDuAWejxfLvJp7yNS5HjHuXNr4p2L+2Iu KL+lXSJpMzIvC51bW1TayB4rhshj9kBEaR4YxfPOaEf68UxKrxfrZYjqJ6eN0l/JMqs2 S1DXnTdVxK16dp1R/rEG27qcx1NNqaI/fuuU3lNUCxEZt3mfdI58A6HSuJ9P03KpqJyO FYbIcx++4OJDfy3Elua9tN/9vkXrBULGAgcekyr+A9K5LvFM+8dVqEGh8u9WjyNN5fj+ 2TDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=7dQF10nA4DcBWsWq2WNrdG4CFJHiBcNY5kMHGDXDtrM=; b=rxaIj6qsrW7IyChgXjBuno4xQDbjh/YvjVL+Mv6VNETxamRvBFsbkVksDvGD/igCdD F3NK4mEVz3yBXoapMmlyh9zclLTPIRrcWHEUa2ceQjqtHgoQJLZRgZxSCRlZTK3pAIpY 0471COWmnEl1DB4R4+VqeTInFIsA+V29gq8PV2gRdpkORHqoqHIxqxOQNMKih82CUCM0 b21tyxEfZIyN80Eslp7WpvkTp9adVwZHol4D59gze1Z1Cevbbb9LE+5bXVUFH933fBSp C+u3f5jCL96Av+gPmUpsG6UOlNRZ4WcJoInP1HgvIQdfwCPIihnSv9ymqC69R90NyIvv 4lAg==
X-Gm-Message-State: APjAAAWxtbbYvsdXSbft3LJEi1UrrIA8xbTr+UlVtbzIk0qODQFq/wgD 17PYuYaCzG7XApgbKkWH3W9XCqwx
X-Google-Smtp-Source: APXvYqyrfiRkt4ypI5r6FTv59nl+wl1nMTVWPLqt7mEM3Lh7LIVuRT6FGeJLE55AHyQKwJnTexajRw==
X-Received: by 2002:a02:a85:: with SMTP id 127mr11430668jaw.107.1552918533459; Mon, 18 Mar 2019 07:15:33 -0700 (PDT)
Received: from ?IPv6:2607:fea8:69f:f5eb:fc5f:12b:d173:619a? ([2607:fea8:69f:f5eb:fc5f:12b:d173:619a]) by smtp.gmail.com with ESMTPSA id x19sm4295667iob.61.2019.03.18.07.15.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Mar 2019 07:15:32 -0700 (PDT)
To: =?UTF-8?Q?G=c3=b6ran_Selander?= <goran.selander@ericsson.com>, John Mattsson <john.mattsson@ericsson.com>
Cc: "secdispatch@ietf.org" <secdispatch@ietf.org>, 'Benjamin Kaduk' <kaduk@mit.edu>, "ace@ietf.org" <ace@ietf.org>
References: <C79F1336-A297-4E64-AB32-2F5D474A200E@ericsson.com> <20181103145857.GG54966@kduck.kaduk.org> <7F78CC92-5C48-4BFC-8087-E25D4D95A74F@ericsson.com> <000001d481ae$57cd4530$0767cf90$@augustcellars.com> <B119A1D8-08B5-431E-BB16-35D84AA6F6CB@ericsson.com> <8155ccb8-6b44-cd49-caae-8915ef0cef7d@gmail.com> <89483a94-8c12-9fc7-a4ed-75fb250beb14@gmail.com> <985573C6-A4A6-4CDE-BDC6-6E53EE80C025@ericsson.com> <087b4e56-fed8-ea17-5d02-882ff34665ad@gmail.com> <2cd05b52-c0de-18b1-c152-cc8b7c4f887b@gmail.com> <065BA537-5AC7-46A3-A08C-4403FC80E13F@ericsson.com>
From: Rene Struik <rstruik.ext@gmail.com>
Message-ID: <60778d95-053b-1bbf-d7c8-c33ef490b255@gmail.com>
Date: Mon, 18 Mar 2019 10:15:29 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <065BA537-5AC7-46A3-A08C-4403FC80E13F@ericsson.com>
Content-Type: multipart/alternative; boundary="------------9E721D7C76146E1D19F3F5C9"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/wIxzt994DC1WwsMzf6zdCntHGs4>
Subject: Re: [Ace] (details on use case scenario?) Re: [Lwip] EDHOC standardization
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Mar 2019 14:15:38 -0000

Hi Goran:

Unfortunately, it is not clear at all. Details matter: one cannot simply 
wave a magic wand ("not yet defined, but is expected to", etc, etc.).

I am not a big believer in protocol design by email exchange. Security 
protocol design is hard, as is also evidenced by the document history of 
[1], where the initial document was produced in Sep 2016, adopted as WG 
document in Nov 2016, relabeled as another WG document sprout in Sep 
2017 ... and now it is March 2019. Doesn't protocol design start on a 
white board, where one has an initial idea and then systematically work 
through issues, revisits assumptions, etc., rather than produce 
documents and then write the rationale after the fact?

I do not understand the current flurry of emails to push a particular 
design through: why not first coming up with a design requirements 
document that goes further than "byte-count" arguments?

One can do more analysis in the prelude to Montreal, but this is only 
meaningful if one does not cast things in concrete first and then ask 
for feedback, with some external "clients" (including the 6tisch use 
case that I questioned) as motivation. I do understand the motivation to 
claim a stake, but if intention is to reach a billion+ devices, I think 
the bar should be really high.

Ref: 
[1]https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-join/

[excerpt of what you wrote below]
6TiSCH minimal security [4] specifies how a Pledge joining a new network 
communicates using CoAP with the JRC via a Join Proxy and over 
additional hops. The proxy operations in the Join Proxy incurs certain 
overhead in the communication between Proxy and JRC. The exact procedure 
for the zero-touch is not yet defined, but it is expected to reuse 
features of the Join Proxy in the minimal security setting. The 
benchmark in [2] is based on this setting but replacing the OSCORE 
protection of CoAP with the AKE protocol messages carried over CoAP. *Is 
it more clear now?*

On 3/18/2019 6:08 AM, Göran Selander wrote:
>
> Hi Rene,
>
> Sorry for slow response to your mails.
>
> *From: *Rene Struik <rstruik.ext@gmail.com <mailto:rstruik.ext@gmail.com>>
> *Date: *Friday, 15 March 2019 at 15:28
> *To: *Göran Selander <goran.selander@ericsson.com 
> <mailto:goran.selander@ericsson.com>>, John Mattsson 
> <john.mattsson@ericsson.com <mailto:john.mattsson@ericsson.com>>
> *Cc: *"secdispatch@ietf.org <mailto:secdispatch@ietf.org>" 
> <secdispatch@ietf.org <mailto:secdispatch@ietf.org>>, 'Benjamin Kaduk' 
> <kaduk@mit.edu <mailto:kaduk@mit.edu>>, "ace@ietf.org 
> <mailto:ace@ietf.org>" <ace@ietf.org <mailto:ace@ietf.org>>
> *Subject: *Re: [Ace] (details on use case scenario?) Re: [Lwip] EDHOC 
> standardization
>
> Hi Goran:
>
> As you recall, I suggested to look at some details of 6TiSCH 
> enrollment (see my message of March 4, 2019 [1]). During the 
> SecDispatch interim of March 5, 2019, this was provided as one use 
> case scenario [2] and reiterated in your email of yesterday, March 14, 
> 2019 [3]. Nevertheless, details on how this could be realized in 
> practice are still missing.
>
> I had another look at the 6TiSCH minimal security draft [1] (now in 
> 2nd WGLC) and the "zero-touch" write-up [5] -- which you both 
> referenced in your email [3] of yesterday.
>
> To my understanding, the intention with 6TiSCH is to reuse the 
> protocol flows of [4] to implement a public-key based enrollment 
> scheme in the future. This seems to be what [5] aims for, if I try and 
> read in between the [still unwritten] lines, and the impression I got 
> from some people. From looking at the protocol details, though, I do 
> not understand how this can be done in practice. This begs the 
> question what I am missing here.
>
> Hence, my question of March 4th on details of use case scenarios still 
> stands. In fact, I do not see how one could implement EDHOC on top of 
> [4], even if one only uses symmetric-key only variant of EDHOC.
>
> If you could shed some light on this, this would help. Or, should we 
> simply abandon that use case as being unrealistic at this point?
>
> 6TiSCH minimal security [4] specifies how a Pledge joining a new 
> network communicates using CoAP with the JRC via a Join Proxy and over 
> additional hops. The proxy operations in the Join Proxy incurs certain 
> overhead in the communication between Proxy and JRC. The exact 
> procedure for the zero-touch is not yet defined, but it is expected to 
> reuse features of the Join Proxy in the minimal security setting. The 
> benchmark in [2] is based on this setting but replacing the OSCORE 
> protection of CoAP with the AKE protocol messages carried over 
> CoAP. Is it more clear now?
>
> Finally, your email [1] suggests "reports of massive breaches with PSK 
> provisioning systems". If so, I would strongly suggest having another 
> look at [4] and commenting on this.
>
> I’m not sure exactly what you want me to comment on. Clearly there are 
> weakness with PSK based systems w/o PFS. But PSK w/o PFS is still used 
> for various reasons, including inability to deploy better security. 
> This inability may be real due to performance limitations or only 
> perceived, for example due to unawareness of intermediary provisioning 
> schemes between PSK and certificates, but in any case PSK w/o PFS is 
> clearly a better alternative than no security at all. One purpose of 
> the work we discuss here is to lower the threshold for PFS.
>
> You mentioned in a previous mail other limitations in the multi-hop 
> setting besides message sizes, and that is indeed true - this is just 
> one benchmark. Is there some specific characteristic you want to 
> highlight in this context?
>
> RS>> My 10-hop enrollment use case was aimed to force consideration of
>
> not just abstract "protocol flow arrows", but also effects on the
>
> network and its actors. A simple byte-count is not enough...
>
> <<RS
>
> Göran
>
> Ref:
>
> [1] Details on Use Case Scenarios, email RS of March 4, 2019. 
> Seehttps://mailarchive.ietf.org/arch/msg/ace/On0iIFAb_OWeBqLjlryi1rBHwhk
>
> [2] Slides on EDHOC during SecDispatch meeting of March 5, 2019. 
> Seehttps://datatracker.ietf.org/meeting/interim-2019-secdispatch-01/materials/slides-interim-2019-secdispatch-01-sessa-edhoc.pdf
>
> [3] Pitch for EDHOC, email Goran Selander of March 14, 2019. 
> Seehttps://mailarchive.ietf.org/arch/msg/secdispatch/vNR7nT20fsvYjYXhAPjOpLjZGCU
>
> [4] draft-ietf-6tisch-minimal-security-09
> [5] draft-ietf-6tisch-dtsecurity-zerotouch-join-03
>

-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363