Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

["Igoe, Kevin M." <[e-mail]>]

I'll agree with David's position, but for a slightly different reason.  A packet with a bad MAC may mean
the decrypted PT is malicious.  Not decrypting CT with a bad MAC cryptographically enforces the policy
that questionable packets MUST NOT be released to the receiving user/processes.

Misuse of AES-CBC-HMAC-SHA (we really need a shorter name) by a well intentioned application programmer
is, in my opinion, the larger risk.  By never even decrypting questionable CT there is no chance the programmers
will, with the best of intentions,   make a security critical mistake by acting upon malicious PT.

From: [e-mail] [mailto:[e-mail]] On Behalf Of David Jacobson
Sent: Tuesday, November 20, 2012 12:00 AM
To: [e-mail]
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

I think I'd argue the other way on continuing on on when the MAC fails.

One big advantage of encrypt-then-MAC is that the receiving end does MACverify-then-decrypt.  If the message has been tampered with, the MAC fails to verify and we never even enter the decryption stuff, thus there is never even the possibility of padding oracles, timing attacks, etc.  If you go ahead with the decryption, you risk revealing something.

   --David



On 11/18/2012 10:44 AM, Tolga Acar wrote:
Quick feedback on the draft


*         Page 5, item 3, padding string PS. Please \cite PKCS#5 so it is clear this is not new, but a reuse of an existing padding scheme.

*         Section 2.2, step 3. When MAC verification fails, the draft recommends halting the operation before CBC decryption. We have seen timing and error-code based attacks against TLS' MAC-then-Encrypt scheme. I realize that the draft is prescribing E-t-M. Nonetheless, considering a potential flaw in HMAC-SHA2 series (I don't know of any, but ...), I'd suggest not halting the operation even after MAC check fails, but continuing on to CBC decryption, and then returning an error that doesn't distinguish between a MAC and a decryption (pad check) error. Yes, this would consume more CPU cycles only to waste them *under an attack*, which is not necessarily bad.

*         Section 2.2, step 5. Unspecified error case of invalid padding (link to my comment above).

Best,

-          Tolga

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Russ Housley
Sent: Sunday, November 18, 2012 4:45 AM
To: Mike Jones
Cc: IRTF CFRG; [e-mail]<mailto:[e-mail]>
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

Have you looked at the algorithm in RFC 6476?  While the discussion is CMS-specific, the algorithm could be used with another syntax.

Russ


On Nov 12, 2012, at 1:55 PM, Mike Jones wrote:



As background, if there was a version of this spec that did not assume that the parameters would be concatenated together in a specific way, but left them as independent inputs and outputs, as AES GCM and AES CTR do, it would be a better match for JOSE's use case.

                                                            -- Mike

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of David McGrew (mcgrew)
Sent: Monday, November 12, 2012 10:21 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

Hi,

There is a new version of "Authenticated Encryption with AES-CBC and HMAC-SHA", and I would appreciate your review.   It is online at <https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/?include_text=1><https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/?include_text=1%3e>   The diff between the current and the previous version is available at <http://www.ietf.org/rfcdiff?url2=draft-mcgrew-aead-aes-cbc-hmac-sha2-01><http://www.ietf.org/rfcdiff?url2=draft-mcgrew-aead-aes-cbc-hmac-sha2-01%3e>

This draft has been proposed for use in the JOSE WG <http://datatracker.ietf.org/wg/jose/><http://datatracker.ietf.org/wg/jose/%3e> , where its adoption would allow the working group to omit "raw" unauthenticated encryption, e.g. AES-CBC, and only include authenticated encryption.   Thus I am asking for your help in making

John Foley generated test cases that correspond to the current version of the draft, but I didn't include these in the draft because I did not yet get confirmation from a second independent implementation.   With hope, there will not be any need for any normative changes, and I will include these after I get confirmation.

Thanks,

David
_______________________________________________
Cfrg mailing list
[e-mail]<mailto:[e-mail]>
http://www.irtf.org/mailman/listinfo/cfrg





_______________________________________________

Cfrg mailing list

[e-mail]<mailto:[e-mail]>

http://www.irtf.org/mailman/listinfo/cfrg