Re: [Emu] New Version Notification for draft-janfred-eap-fido-02.txt

[Heikki Vatiainen <[e-mail]>]

On Tue, 5 Mar 2024 at 09:56, Alexander Clouter <[e-mail]>
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
[e-mail]