Sounds good to me. -----Original Message----- From: Russ Housley <[email protected]> Date: Friday, 14 May 2021 at 21:21 To: John Mattsson <[email protected]> Cc: cose <[email protected]> Subject: Re: [COSE] draft-ietf-cose-countersign-02 - Secruity problems with COSE_Encrypt and COSE_Encrypt0 with CCM_8
John: Thanks. I wonder it it would be better go a bit higher level. I am not sure that the external_add really has an impact on choosing whether the COSE_Mac is a good countersign mechanism. I think there are two points: 1) When either COSE_Encrypt and COSE_Mac is used and more than two parties share the key, data origin authentication is not provided. Any party that knows the message-authentication key can compute a valid authentication tag; therefore, the contents could originate from any one of the parties that share the key. 2) Countersignatures of COSE_Encrypt and COSE_Mac with short authentication tags do not provide the security properties associated with the same algorithm used in COSE_Sign. To provide 128-bit security against collision attacks, the tag length MUST be at least 256-bits. A countersignature of a COSE_Mac with AES-MAC 256/128 provides at most 64 bits of integrity protection. Similarly, a countersignature of a COSE_Encrypt with AES-CCM-16-64-128 provides at most 32 bits bits of integrity protection. What do you think? Russ > On May 13, 2021, at 8:04 AM, John Mattsson > <[email protected]> wrote: > > Hi Russ, > > I made a PR with a first draft of such text > > https://protect2.fireeye.com/v1/url?k=6986d68b-361def8b-69869610-86fc6812c361-168e94aab5dee6e2&q=1&e=c50492cc-e1eb-4f25-b1ab-871818930a05&u=https%3A%2F%2Fgithub.com%2Fcose-wg%2Fcountersign%2Fpull%2F6 > > "Countersignatures of COSE_Encrypt and COSE_Mac with short tags and non-empty > external_aad do not at all give the security properties normally associated > with the same algorithm used in COSE_Sign. To provide 128-bit security > against collision attacks, the tag length MUST be at least 256-bits. A > countersignature of a COSE_Mac with AES-MAC 256/128 only gives 64-bit > security and a countersignature of a COSE_Encrypt with AES-CCM-16-64-128 only > gives 32-bit security. Another solution is to provide the same external_aad > used in the COSE_Encrypt and COSE_Mac to the countersignature algorithm, but > this external_aad is typically not available to the party performing or > verifying the countersignature." > > Cheers, > John > > -----Original Message----- > From: Russ Housley <[email protected]> > Date: Monday, 15 March 2021 at 17:58 > To: John Mattsson <[email protected]> > Cc: cose <[email protected]> > Subject: Re: [COSE] draft-ietf-cose-countersign-02 - Secruity problems with > COSE_Encrypt and COSE_Encrypt0 with CCM_8 > > John: > > Are you asking for addition text in the security considerations to warn > against short MACs? If so, can you provide the first draft of such text? > > Russ > > >> On Mar 12, 2021, at 3:12 AM, John Mattsson >> <[email protected]> wrote: >> >> Hi, >> >> When I analysed an earlier version of Group OSCORE some years ago it had >> severe security problems when used with CCM_8 + Countersignature. The >> attacks were pretty bad. 64-bit offline complexity against source >> authentication/availability from a different person in the group and >> something slightly over 32-bit online security (collecting 2^32 messages) >> against a source authentication/availability from a third party outside of >> the group. The problem was that the countersignature relied on the AEAD tag >> for integrity protection of the additional data. This was fixed in Group >> OSCORE be adding all the additional data to the signature as well. >> >> The use case of Countersignatures is "Countersignatures provide a method of >> having a second party sign some data." In this case I don't think CCM_8 + >> Countersignature provides the expected security. Unless you can put all the >> additional data to the signature as well, I think CCM_8 + Countersignature >> needs to be forbidden. >> >> I don't really see why Group OSCORE is using countersign in the first place, >> it seems like a relic from a time when it was assumed that OSCORE would be a >> single COSE structure on the wire as well. >> >> Cheers, >> John > > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
