Re: using authenticated encryption in webcrypto

On Fri, Jun 15, 2012 at 9:24 AM, David McGrew <mcgrew@cisco.com> wrote:

> Hi,
>
> I propose that webcrypto encourage the use of authenticated encryption
> with associated data (AEAD) instead of non-authenticated symmetric
> encryption such as raw CBC mode.   From a security perspective, it would be
> best to only allow encryption that is tightly bound to authentication, but
> I am suggesting that the standard make AEAD a should-implement and not a
> must-implement for the obvious reason of backwards compatibility with
> existing implementations.
>
> There are dedicated AEAD modes like CCM and GCM, but some implementations
> may want to use CBC and HMAC because those modes are already implemented,
> or because the do not want to manage the deterministic nonces that CCM and
> GCM require.  I recently submitted a draft (joint work with Kenny) that
> defines AEAD algorithms based on CBC and HMAC.   I believe that this work
> would be suitable for use in webcrypto, and would actually simplify the
> API.   For instance, in David Dahl's algorithm ideas, the CBC-HMAC
> algorithms would have the same interface as the GCM algorithm.
>
> The draft is at <
> http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-00>; here
> is the abstract:
>
>   This document specifies algorithms for authenticated encryption with
>   associated data (AEAD) that are based on the composition of the
>   Advanced Encryption Standard (AES) in the Cipher Block Chaining (CBC)
>   mode of operation for encryption, and the HMAC-SHA message
>   authentication code (MAC).
>
>   These are randomized encryption algorithms, and thus are suitable for
>   use with applications that cannot provide distinct nonces to each
>   invocation of the AEAD encrypt operation.
>
> Comments on the draft itself and on suitability for this WG are welcome.
>
> I have been on travel recently and I am not caught up with all threads on
> the list yet; apologies if I have missed some prior discussion of these
> points.
>
> regards,
>
> David
>
>
David,

+1 to supporting AEAD.

However, I'm not sure I'd agree with the statement that simplifies the API
any, so I was hoping you could explain. As I see it, It would only simplify
things if some API was being removed, but I understand that you're
specifically not proposing that non-authenticated encryption be prohibited.
And while AEAD offers compelling properties for tamper resistance, I
imagine there will still be a desire for authenticity checks via asymmetric
keys and/or key wrapping, so we don't necessarily lose those interfaces
either.

Have I missed something fundamental in your proposal?

Cheers,
Ryan