On Tue, 5 Mar 2024 at 09:56, Alexander Clouter <alex+i...@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 -- Heikki Vatiainen h...@radiatorsoftware.com
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
