I understand the issues that have been discussed: (1) feature completeness of the specification, (2) availability of implementations, and (3) compactness of the binary encoding. We initially, in 2016, considered ASN.1, CBOR and JSON as equal candidates and rejected CBOR because the specification and implementation were not mature at the time. While CBOR now has both the features (issue 1) and implementations (issue 2), I hesitate to make such a big change so late in the standardization process. The compactness of the binary representation (issue 3) make little difference because EAP-NOOB is a bootstrapping protocol; the efficiency gains of CBOR would be more significant in payload data or signaling that continues throughout the device lifetime.
There is, however, another issue that always bothered me much more. It is the ability to verify the HMAC correctly. That is, my biggest concern with both JSON and CBOR is (4) the lack of canonical binary serialization. IN EAP-NOOB, we need to receive a serialized data message, extract some fields and subtrees, compose an HMAC input out of these parts of the data, and reliably compute always the same HMAC on it. The easy but flawed implementation would be to decode the received message, extract the selected parts, and then re-encode them, but the lack of canonical encoding means that the resulting byte string could be different in different encoder/decoder implementations. For the above reason, we have to extract the unmodified binary encoding of received messages. Some JSON libraries provide access to the unmodified binary encoding of document parts, but many either have no such function, return the Unicode serialization but no binary one, or do not guarantee that the returned byte string is unmodified. When we initially looked at CBOR, I expected it to solve this problem but found that, just like for JSON, there was no such function and we had to read the code of the decoder/encoder implementations to figure out a solution. A theoretical advantage of CBOR over JSON in this respect is that CBOR is serialized directly to a byte string while JSON is serialized to a Unicode string, which is then encoded as a byte string. This means that it may be easier for a CBOR library to provide access to the unmodified binary representation of fields and subtrees of received messages. But if the specification does not require them to provide that access, there is no real difference to JSON. Tuomas -----Original Message----- From: Emu <emu-boun...@ietf.org> On Behalf Of Carsten Bormann Sent: Saturday, 11 July, 2020 16:40 To: Mohit Sethi M <mohit.m.sethi=40ericsson....@dmarc.ietf.org> Cc: draft-ietf-emu-eap-noob....@ietf.org; emu@ietf.org; Dave Thaler <dtha...@microsoft.com>; iot-director...@ietf.org Subject: Re: [Emu] [Iot-directorate] Iotdir early review of draft-ietf-emu-eap-noob-01 Importance: High Hi Mohit, > On 2020-07-11, at 15:27, Mohit Sethi M > <mohit.m.sethi=40ericsson....@dmarc.ietf.org> wrote: > > Hi Michael, > > Thanks for the input. This is indeed something we should discuss at the > upcoming virtual EMU meeting. > > Some colleagues (Ingles Sanchez et al.) have also investigated and documented > the savings that might result from the use of CBOR in EAP-NOOB: > https://hal.archives-ouvertes.fr/hal-02880326/document That paper simply translates a JSON-like structure into CBOR, without using any of the additional benefits of using CBOR (e.g., numeric map labels). So I would expect the benefits of moving to CBOR to be larger than described in this paper. > EAP-NOOB also relies on the JWK specification for encoding public keys. While > CBOR equivalent is defined in RFC 8152, it is a rather large document that > contains all the functionality of JWK, JWS, JWA (as far as I understand). > Following smaller modular specifications was somehow easier at the time. RFC 8152 does have a section structure, so you don’t need to read all of it to just get the equivalent of JWK. > What is more important is that wpa_supplicant currently has a JSON encoder > and parser (https://w1.fi/cgit/hostap/tree/src/utils/json.c). I think you > would agree that wpa_supplicant is probably the most important tool for those > using EAP (at least on 802.11). > > One could use an external library since there are many CBOR implementations > available: https://cbor.io/impls.html. However this has two major downsides: > > - Adding an external library dependency implies that the overall system > becomes more brittle. To the contrary. An implementation of JSON just for one application is likely to have received less testing and overall development attention than an industrial-strength library. If you for some reason don’t agree with that, you can always create another CBOR implementation in an afternoon :-) > - Updating and maintaining two components is definitely harder than one. Not sure I follow. > As said, this is worth discussing at the meeting since it would result in a > large change to the existing EAP-NOOB implementations. Certainly! I just wanted to make sure you don’t make your decision for the wrong reasons. Grüße, Carsten _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
