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....@gmail.com <mailto:rstruik....@gmail.com>>
*Date: *Friday, 15 March 2019 at 15:28
*To: *Göran Selander <goran.selan...@ericsson.com
<mailto:goran.selan...@ericsson.com>>, John Mattsson
<john.matts...@ericsson.com <mailto:john.matts...@ericsson.com>>
*Cc: *"secdispa...@ietf.org <mailto:secdispa...@ietf.org>"
<secdispa...@ietf.org <mailto:secdispa...@ietf.org>>, 'Benjamin Kaduk'
<ka...@mit.edu <mailto:ka...@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....@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
