Re: [COSE] COSE Support for AES-CTR and AES-CBC

Sorry, I had the wrong email address for Scott.

I’m trying to understand some of the concerns that have been raised. I
understand that AES-GCM is not exposed to the concerns that Sophie and has
raised?

If we used AES-GCM with out of order reception and on-the-fly decryption,
would that mitigate the risks?

Best Regards,
Brendan

On Mon, 7 Nov 2022 at 11:03, Brendan Moran <brendan.moran.ietf@gmail.com>
wrote:

> I talked with Scott Fluhrer today about this use case and he’s pointed out
> that GCM can be processed out of order.
>
> Scott, would you be able to elaborate on this?
>
> Best Regards,
> Brendan
>
> On Wed, 26 Oct 2022 at 22:51, Russ Housley <housley@vigilsec.com> wrote:
>
>> Scott:
>>
>> Introducing AES-CTR and/or AES-CBC into COSE tokens that already support
>> AES-GCM will open the GCM implementations to new security issues. Namely,
>> potential padding oracle vulnerabilities.
>>
>>
>> I think that adding a reference to the existing paragraph in the Security
>> Considerations will address this concern:
>>
>>    With AES-CBC mode, implementers SHOULD perform integrity checks prior
>>    to decryption to avoid padding oracle vulnerabilities [Vaudenay].
>>
>> At minimum, the Security Considerations section of
>> draft-ietf-cose-aes-ctr-and-cbc-01 needs to call this risk out:
>> Applications that encrypt or decrypt with AES-GCM *MUST NOT* support
>> AES-GCM or AES-CTR with the same cryptographic materials, due to the
>> existence of cross-protocol issues. One way to safeguard users from
>> potential misuse is to use a separate "type" for keys used with
>> unauthenticated encryption modes; similar to how COSE distinguishes MACs
>> from Signatures.
>>
>>
>> I suggest an addition paragraph in the Security Considerations:
>>
>>    To avoid cross-protocol concerns, implementations MUST NOT use the
>>    same keying material with AES-CTR and AES-GCM.  Likewise,
>>    implementations MUST NOT use the same keying material with AES-CTR
>>    and AES-CCM.
>>
>> Additionally, I'd like to recommend sharing this draft with the CFRG
>> mailing list to ensure it has the appropriate level of oversight from the
>> IETF's cryptography experts.
>>
>>
>> AES-CTR and AES-CBC are not new cryptographic modes.  New techniques
>> deserve CFRG review, but AES-CTR and AES-CBC have been included in RFCs for
>> many years.
>>
>> Russ
>>
>> _______________________________________________
>> COSE mailing list
>> COSE@ietf.org
>> https://www.ietf.org/mailman/listinfo/cose
>>
>