On 05.03.24 10:33, Heikki Vatiainen wrote:
On Tue, 5 Mar 2024 at 09:56, Alexander Clouter <alex+i...@coremem.com <mailto:alex%2bi...@coremem.com>> wrote:Using an entire serialiser to support only a map carrying attributes with 1->3 *predetermined* keys seems a bit of a cannon to deal with a mosquito solution as they go. As a hypothetical, would people have a stronger opinion here if CBOR was swapped for protocol buffers or ASN.1 in the document?Ok, I'll bite. I've worked recently with ASN.1 (hello GSM world) and found it much easier to work than I initially though. I found the interoperability of different MAP and TCAP (again GSM) implementations to work well together. In other words, the software I made successfully talked to other software from the beginning. This allowed the work to concentrate on the software functionality instead of serialising bits on the line.I'd say the main point is: use encoding that's appropriate for the task. ASN.1 suits for 2G/3G complex things. Simple TLVs have so far worked well with EAP.I haven't worked with CBOR, but I'd be interested to know if, for example, how careful we need to be with serialiser/deserialiser to avoid problems similar to exponential expansions attacks [1], etc. TLVs are known for people working on Radius/Diameter/EAP. With CBOR it would be useful if the draft were to have information to avoid potential problems, especially if the CBOR input can come from untrusted sources. I'm sure this information is available, and it would help the implementers if they're notified about what to look out for, if needed.[1] https://en.wikipedia.org/wiki/Billion_laughs_attack <https://en.wikipedia.org/wiki/Billion_laughs_attack>
Well, the beauty of CBOR is that it is very easily extendable.I completely agree that, with the limited list of map keys, using CBOR instead of TLVs seems like shooting cannons at mosquitos, but if in the future we want to do more with this, we can.
Resource exhaustion is a problem in CBOR, as it is in any other serialization/deserialization solution.
Here a quote from the CTAP2 spec regarding the use of CBOR in CTAP2 and how they deal with the problem:
https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#message-encoding
Because some authenticators are memory constrained, the depth of nested CBOR structures used by all message encodings is limited to at most four (4) levels of any combination of CBOR maps and/or CBOR arrays. Authenticators MUST support at least 4 levels of CBOR nesting. Clients, platforms, and servers MUST NOT use more than 4 levels of CBOR nesting.
They also limit the length of a CBOR message, with a recommendation that every authenticator MUST support at least messages of 1024 bytes and that platforms have to respect the max message length signaled by the authenticator.
We could say something similar about the allowed depth and length of the CBOR messages sent in EAP-FIDO.
One thing that I still have to look into is how we would deal with multiple Discoverable Credentials registered for the same RPID, one solution would be to send a signature from all of them, and at least then I would put the tuple (Credential ID, authdata, signature) in a CBOR map, and have the possibility to put multiple of these maps in the message.
I'll try to get some Face2Face time with some CBOR experts and talk to them about the way they would suggest using CBOR in this protocol.
Cheers, Janfred -- Herr Jan-Frederik Rieckers Security, Trust & Identity Services E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370 Pronomen: er/sein | Pronouns: he/him __________________________________________________________________________________DFN - Deutsches Forschungsnetz | German National Research and Education Network
Verein zur Förderung eines Deutschen Forschungsnetzes e.V. Alexanderplatz 1 | 10178 Berlin https://www.dfn.deVorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | Christian Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch VR AG Charlottenburg 7729B | USt.-ID. DE 136623822
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
