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

[Alan DeKok <[e-mail]>]

On Mar 5, 2024, at 5:46 AM, Jan-Frederik Rieckers <[e-mail]> wrote:
> 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.

  Extensibility also has its downsides.  If we're not sure we need the functionality, then *unused* functionality is ripe for exploits or issues.

> Resource exhaustion is a problem in CBOR, as it is in any other serialization/deserialization solution.

  If we only need 3 pieces of data, none nested, then CBOR has more issues than TLVs, due to it's inherent nesting.

  i.e. the temptation for implementors is to pass the raw CBOR data to a CBOR library.  Which means nested structures, complex maps, etc.  And none of that will be used by EAP-FIDO.

  For now I'd suggest concentrating on getting the crypto right, and the request / response exchange.  Data encoding can always be changed before it's widely implemented.

> 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.

  So EAP-FIDO would also need to negotiate / signal message length?

> We could say something similar about the allowed depth and length of the CBOR messages sent in EAP-FIDO.

  Is that fixed, or negotiated?

  Alan DeKok.