Re: [Ace] (details on use case scenario?) Re: [Lwip] EDHOC standardization
Hi Rene,
There are two things which has a bearing on the topic we try to progress here:
1. assessing that a certain benchmark is relevant for a particular OSCORE
deployment, and
2. assessing how well a solution performs with respect to the benchmark.
I made an attempt to explain one instance of item 1 – people can look up for
themselves in [arch] or [0-touch] the protocol flow, the endpoints for the AKE
(the Pledge and the JRC) and the role of the proxy (as in the Minimal Security
protocol). This information is sufficient for defining the benchmark we are
discussing here.
But at the end of the day, it is the users of OSCORE that should evaluate item
1, in this case the 6tisch WG. And this is what happened at the interim when a
person active in 6tisch presented the quantification of the benchmark. The
discussion about status of 6tisch drafts or potential new design requirement
documents is probably better to have on the 6tisch mailing list than on these
lists.
Göran
[arch] draft-ietf-6tisch-architecture-20
[0-touch] draft-ietf-6tisch-dtsecurity-zerotouch-join-03, section 2.4-2.5
From: Rene Struik
Date: Monday, 18 March 2019 at 15:15
To: Göran Selander , John Mattsson
Cc: "secdispa...@ietf.org" , 'Benjamin Kaduk'
, "ace@ietf.org"
Subject: Re: [Ace] (details on use case scenario?) Re: [Lwip] EDHOC
standardization
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 mailto:rstruik@gmail.com>>
Date: Friday, 15 March 2019 at 15:28
To: Göran Selander
mailto:goran.selan...@ericsson.com>>, John
Mattsson mailto:john.matts...@ericsson.com>>
Cc: "secdispa...@ietf.org<mailto:secdispa...@ietf.org>"
mailto:secdispa...@ietf.org>>, 'Benjamin Kaduk'
mailto:ka...@mit.edu>>, "ace@ietf.org<mailto: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
Re: [Ace] (details on use case scenario?) Re: [Lwip] EDHOC standardization
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 mailto:rstruik@gmail.com>>
*Date: *Friday, 15 March 2019 at 15:28
*To: *Göran Selander <mailto:goran.selan...@ericsson.com>>, John Mattsson
mailto:john.matts...@ericsson.com>>
*Cc: *"secdispa...@ietf.org <mailto:secdispa...@ietf.org>"
mailto:secdispa...@ietf.org>>, 'Benjamin Kaduk'
mailto:ka...@mit.edu>>, "ace@ietf.org
<mailto: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, includin
Re: [Ace] (details on use case scenario?) Re: [Lwip] EDHOC standardization
Hi Rene, Sorry for slow response to your mails. From: Rene Struik mailto:rstruik@gmail.com>> Date: Friday, 15 March 2019 at 15:28 To: Göran Selander mailto:goran.selan...@ericsson.com>>, John Mattsson mailto:john.matts...@ericsson.com>> Cc: "secdispa...@ietf.org<mailto:secdispa...@ietf.org>" mailto:secdispa...@ietf.org>>, 'Benjamin Kaduk' mailto:ka...@mit.edu>>, "ace@ietf.org<mailto: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... <https://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 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] (details on use case scenario?) Re: [Lwip] EDHOC standardization
Hi John, Goran:
It is not easy to follow the discussion on EDHOC (except for witnessing
a byte-count slinging contest on the mailing list).
I think it would be good to look at the big picture, i.e., which problem
does one solve and/or does one solve the right problem.
I would like to understand somewhat better how the scheme suggested in
[1] could help in facilitating fast network enrollment and network
formation.
Could you describe how to use this in the following scenario:
1) Network with one central manager and N=1,000 nodes that wish to join
the network roughly at the same time, where the network manager is, say,
10 hops away from the joining nodes;
2) Authenticated key agreement using cert-based key agreement;
3) Network uses time-synchronized scheduling (such as in 6tisch) - where
local single-hop communication time latency is 10 seconds);
4) The network manager may have high-bandwidth with outside world, but
joining node/network manager path uses relatively low-bandwidth pipe
that may only be available intermittently, with preset schedule);
5) It is unknown beforehand which entry point the joining nodes will
pick when trying to enroll to the network?
While the draft refers to lots of details from other protocols that are
used under the hood, it would be good to abstract from this for now and
describe basics first.
I tend to agree with others that lossless data compression could result
in some savings, with some give and take re encoding rules (see also
[2]). Even if one finds a magic compression bullet at zero incremental
cost, though, the more important question is what problem one solves
and/or whether one solves the right problem. {As an aside, 802.15.4
(which is the MAC with the 127-byte payload limit mentioned) does not
easily allow mixed secured/unsecured communications (but I do not think
it is useful to have a side-discussion on that detail right now).}
The other question I have is whether it would be more important to hide
the identity of the joining node in a network enrollment scenario than
to hide the network manager's identity, or the other way around.
From [1], Section 1.1:
EDHOC is optimized for small message sizes and can therefore be sent
over a small number of radio frames. The message size of a key exchange
protocol may have a large impact on the performance of an IoT
deployment, especially in noisy environments. For example, in a network
bootstrapping setting a large number of devices turned on in a short
period of time may result in large latencies caused by parallel key
exchanges.
Ref: [1] draft-selander-ace-cose-ecdhe-12
[2] Email RS as of October 31, 2018, 2.32pm EDT, subject:
https://mailarchive.ietf.org/arch/browse/ace/?q=struik
On 11/22/2018 10:43 AM, Rene Struik wrote:
Hi John:
When comparing protocols, it would be useful to protocol flows
optimization, as follows:
a) optimized for parallelized online computations;
b) optimized for minimization of message flows.
See also slide 6 of my CFRG-83 presentation of March 30, 2012
(slides-83-cfrg-05 attached; I could not find CFRG records online).
The current draft-selander-ace-cose-ecdhe-10 document considers
optimization b), which minimizes the number of message flows, but does
require each party to compute the shared key consecutively, rather
than in parallel (as in optimization a).
With option a), if one really wishes to squeeze as much info into a
128-octet datagram, one can already send A's ephemeral ECDSA signature
key in message flow 1, thereby cutting down the
size of the second message flow of the Sigma protocol depicted in Fig.
1
(https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#page-11)
by 32 octets. This tackles the 120-octet byte count for the second
flow of Fig. 1 quite simply, while leading to a 4-pass protocol flow
(with roughly 70/70/55/55 bytes in flows 1/2/3/4).
Obviously, this presents a trade-off, but quite well be worth it in
settings where online key computations are quite slow on some
platforms and where scheduling (e.g., with TSCH) can now be done with
less consideration of the individual computational capabilities of
devices (since now one does not need to build-in a worst-case 2 x "key
computation back-off" for least capable devices, but can just use the
1x contingency for this).
The parallel version is depicted below.
Party U Party V | C_U, X_U, ALG_1, UAD_1, R_Sig(U;...) |
+->|
| message_1 | | | | C_U, C_V, X_V, ALG_2, R_Sig(V; ...) |
|<-+
| message_2 | | | | S_U, AEAD(K_3; ID_CRED_U, s_Sig(U; CRED_U, aad_3),
PAD_3) |
+->+
| message_3 |
| | | S_V, AEAD(K_2; ID_CRED_V, s_Sig(V; CRED_V, aad_2), UAD_2)| |
+<-|
| message_4 |
