[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 |
Re: [Ace] WGLC for draft-ietf-ace-coap-est
Panos Kampanakis (pkampana) wrote: >> But can't the client just be configured out-of-band with the URIs directly? > That is right. We could mandate only .well-known URIs. But I think we > ought to let a deployment use non-default URIs. For example some > usecase might not want to send the .well-known in the URI to save > transmission bytes and thus use a custom short URI. If the URI change > takes place after deployment client will find that out with a > discovery. Similarly, a usecase might initially not support one of the > optional requests like server-side keygen. If the server adds support > sometime in the future, the client could find out using discovery. And > we ought to let the client be able to recover in case the well-known > request URI fails for some reason and he wants to see what is supported > by the server.That is why we thought it is still worth to keep the > .well-known URIs along with the discovery. also, EST-COAP is a building block for draft-ietf-anima-constrained-voucher (containing constrained BRSKI) so preconfiguration won't work. While constrained BRSKI can operate on .well-known the LDevID renewal might occur with a different server, and so discovery might be worthwhile. There are two reasons for doing the resource discovery: 1) to get a multicast response when looking for a registrar. 2) to get a shorter name to save some bytes. I think that (2) contributes negatively to code-complexity, and so if not for (1), I'd prefer to live on /.well-known only. But, I don't object to having shorter URLs available for those that want to spend the code. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] EDHOC standardization
Hi John, I have a slightly different perspective. ECDHE-PSK is not used because those companies who want to use security on really low end IoT devices use PSKs only and there is a lot of overhead from the public key crypto. We have been offering different ciphersuites that use ECDHE-PSK for a while and the interest was pretty much zero. RPK was a nice idea but it turns out that those who want to deploy IETF IoT security solutions either want to go totally minimalistic (=PSK) or they go for certificates because they have an installed base. That's what we are seeing. As a co-author of the RPK document I have been talking to our Mbed TLS team a lot and they keep telling me that there is no interest. People ask once in a while for it on Github but don’t want to allocate any resources implementing it. To me that's a pretty strong hint of what people want and do not want. Ciao Hannes -Original Message- From: John Mattsson Sent: Freitag, 22. Februar 2019 10:08 To: Hannes Tschofenig ; ace@ietf.org; l...@ietf.org; secdispa...@ietf.org Cc: Benjamin Kaduk ; salvador@um.es Subject: Re: [Ace] EDHOC standardization Hi Hannes, No wonder that ECDHE-PSK is not widely used in (D)TLS when the relevant ECDHE-PSK cipher suites TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 for TLS 1.2 (and similarly ECDHE + PSK + TLS_AES_128_CCM_8_SHA256 for TLS 1.3) were standardized just a few months ago (RFC 8442 and RFC 8446). Luckily most, if not all TLS 1.3 implementations are likely to support ECDHE + PSK + TLS_AES_128_CCM_8_SHA256. Similarly, PRK (RFC 7250) is not supported in many TLS implementations (e.g. it is not supported in mbed TLS). The main use case for RPK and self-signed certificates are not as a replacement for PKI, it's a replacement for symmetrical group keys. My experience is that almost all IoT devices are capable of doing ECDH and doing so is very important as a way to get PFS. As required by RFC 725, IEFT protocols need to mitigate pervasive monitoring and one very effective way is to use PFS. Looking at a lot of currently deployed IoT systems makes me sad, if security is used at all, it is often hop-by-hop and often not over the full path. The systems seldom provide PFS and in many cases use symmetrical group keys where they should not. A common reason that systems do not use PFS is because they think it’s an easy way to enable intercept. IETF has a role to educate and guide people on what to use. I think that IETF should strongly recommend PFS in all use cases and recommend using RPK/ self-signed certificates instead of group keys where possible. A pre-requisite for doing so is to provide protocols that can be used even in very constrained systems. Cheers, John -Original Message- From: Hannes Tschofenig Date: Wednesday, 21 November 2018 at 16:16 To: John Mattsson , "ace@ietf.org" , "l...@ietf.org" Cc: Benjamin Kaduk , "salvador@um.es" Subject: RE: [Ace] EDHOC standardization Hi John, From our experience neither PSK+ECDHE nor RPK usage is common in IoT deployments among the bigger IoT providers. Today, most companies use certificate-based authentication in almost all cases. In some cases plain PSK is used for those cases where devices are particularly constraint. Ciao Hannes -Original Message- From: Ace On Behalf Of John Mattsson Sent: Wednesday, November 21, 2018 4:03 PM To: ace@ietf.org; l...@ietf.org Cc: Benjamin Kaduk ; salvador@um.es Subject: Re: [Ace] EDHOC standardization Hi all, Inspired by the discussion in this thread, I did more detailed calculations of the number of bytes when DTLS 1.3 is used for typical IoT use cases (PSK, RPK, Connection ID). The plan is to add this information to draft-ietf-lwig-security-protocol-comparison as this has been requested by several people. I think some bytes were missing in the earlier estimates for TLS 1.3, and as Ben commented, DTLS 1.3 adds some bytes compared to TLS 1.3. == Flight#1 #2#3 Total -- DTLS 1.3 RPK + ECDHE 149373 213735 DTLS 1.3 PSK + ECDHE 18619057433 DTLS 1.3 PSK 13615057343 -- EDHOCRPK + ECDHE 3812186245 EDHOCPSK + ECDHE 43 4712102 == Number of bytes Assumptions: - Minimum number of algorithms and cipher suites offered - Curve25519, ECDSA with P-256, AES-CCM_8, SHA-256 - Length of key identifiers: 4 bytes - Connection identifiers: 1 byte - The DTLS RPKs use point
