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:*cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] *On Behalf 
> Of *Russ Housley
> *Sent:* Sunday, November 18, 2012 4:45 AM
> *To:* Mike Jones
> *Cc:* IRTF CFRG; jose@ietf.org
> *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:*cfrg-bounces@irtf.org 
> <mailto:cfrg-bounces@irtf.org>[mailto:cfrg-bounces@irtf.org]*On Behalf 
> Of*David McGrew (mcgrew)
> *Sent:*Monday, November 12, 2012 10:21 AM
> *To:*cfrg@irtf.org <mailto:cfrg@irtf.org>;jose@ietf.org 
> <mailto:jose@ietf.org>
> *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
> Cfrg@irtf.org <mailto:Cfrg@irtf.org>
> http://www.irtf.org/mailman/listinfo/cfrg
>
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg