Hi, I think it is important that FIDO can use COSE, IETF should fix this in some way.
I also think it would be generally be good to standardize non-AEAD encryption algorithms. While AEAD should be the default and used in almost all use cases, I think the last years have shown a number of use cases where the integrity protection is not necesary and where forcing applications to send a 8 or 16 byte MAC is not reasonable and would cause significant decreases in performance: 1. TLS 1.3 record layer sequence number encryption. Here 8-16 bytes overhead is not worth it to protect the sequence number confidentiality against active attackers. The sequence number is implicitly integrity protected anyway. 2. EDHOC message_2. Using AEAD here does not improve confidentiality at all as an active attacker can just send its own message_1. Using even a 8 byte tag would require an extra roundtrip in LoraWan and 6TISCH. The information is explicitly integrity protected anyway. 3. Group OSCORE. Group OSCORE currently use AEAD || SIG( AEAD ) wasting 8-16 bytes in each message. Group OSCORE could be significantly improved with a ENC || SIG( ENC + MAC ) construction as this would improve security (SHA-256), lower complexity (early versions were not secure and Group OSCORE aad is now quite complex as a way to be secure but still allow 8 byte tags), and would lower wire format with 8-16 bytes. Sending 8-16 useless bytes is quite much given that CoAP and 2 party OSCORE tries to optimize every single byte. Cheers, John -----Original Message----- From: COSE <[email protected]> on behalf of Göran Selander <[email protected]> Date: Wednesday, 24 February 2021 at 13:11 To: cose <[email protected]> Subject: [COSE] Registration of encryption only COSE algorithms Hi all, We have another request for COSE algorithm assignment that doesn't fit into the existing scheme. FIDO alliance wants to register encryption only (not authenticated encryption) algorithms. As far as I can see, the intent is to achieve authenticated encryption but with the use of separate legacy encryption algorithms together with already registered MAC algorithms. The specification seem to focus on encrypt-then-mac with an example of a COSE_Encrypt0 wrapped in a COSE_Mac0, but mac-then-encrypt is also mentioned. There are no security considerations about either in the specification. Previously, there was a similar request to register legacy algorithm from FIDO alliance resulting in the allocation of code points for secp256k1 and certain RSA algorithms for COSE together with the accompanying RFC 8812 specifying how to use COSE with these algorithms including security considerations. Considering the known issues with separate encryption and MAC, should we for the same reason request an analogous IETF specification also in this case? Göran _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
