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

[Jan-Frederik Rieckers <[e-mail]>]

On 05.03.24 13:40, Alan DeKok wrote:
> 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.

Definitely, and I'm keeping that in mind. (thanks for explicitly 
pointing it out though)

I think there are examples of both. Standards that are too restrictive, 
where people had to misuse some protocol aspects to extend it (or it 
just never reached a noticeable deployment stage, because elements were 
missing and they couldn't extend it without breaking compatibility), and 
too open standards where the extensibility itself was misused and a 
target vector for attacks.

I hope we can find some middle ground where everyone is happy about the 
limitations and the extensibility.

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

+1
The current CBOR message format is actually for me too a reminder of 
what data needs to be sent when and by whom, this won't change if we 
switch to TLVs or use base64url-encoded XML for transmission. (/sarcasm 
hint: ok, the XML is maybe a bit too extreme)

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

Not necessarily. The negotiation between Authenticator and platforn in 
FIDO/CTAP is done because the authenticators possibly have very limited 
capabilities, so they need to negotiate that. For EAP-FIDO I think it 
would be reasonable to just go with the 16k limit for TLS record (if I 
remember correctly this is the limit for one TLS record)

> 
>> We could say something similar about the allowed depth and length of the CBOR messages sent in EAP-FIDO.
> 
>    Is that fixed, or negotiated?

If we stay with CBOR, I would just have that depth fixed in the 
specification. I think it is reasonable to have a limit on there. And if 
some extension in the future wants to have a deeper CBOR structure, 
there is always the possibility to encode the data as byte sequence, so 
implementations that don't understand this can just skip it, but 
implementations which do understand it can send any data they want.

Cheers,
Janfred

-- 
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: [e-mail] | Fon: [phone] | Fax: [phone]
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.de

Vorstand: 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