Re: [kitten] considering abandoning CTS mode (Re: I-D Action:draft-ietf-kitten-aes-cts-hmac-sha2-01.txt)

Tom Yu <tlyu@MIT.EDU> Thu, 15 August 2013 03:26 UTC

To: Michiko Short <michikos@microsoft.com>
References: <5674376E76F88641AD3748A64F0996971AAA4F35@TK5EX14MBXC285.redmond.corp.microsoft.com> <tsly584dyzt.fsf@mit.edu> <5674376E76F88641AD3748A64F0996971AAB7DA1@TK5EX14MBXC285.redmond.corp.microsoft.com> <CAK3OfOgRH88DmtAJw=hgd-t7-Sac3xTf-kD+aYOUCDh79AOtkg@mail.gmail.com>
From: Tom Yu <tlyu@MIT.EDU>
Date: Wed, 14 Aug 2013 23:26:24 -0400
In-Reply-To: <CAK3OfOgRH88DmtAJw=hgd-t7-Sac3xTf-kD+aYOUCDh79AOtkg@mail.gmail.com> (Nico Williams's message of "Wed, 14 Aug 2013 18:57:28 -0500")
Message-ID: <ldv7gfnfxcv.fsf@cathode-dark-space.mit.edu>
Lines: 69
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: "kitten@ietf.org" <kitten@ietf.org>, Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action:draft-ietf-kitten-aes-cts-hmac-sha2-01.txt)
Precedence: list

Michiko Short <michikos@microsoft.com> writes:

> None of us in the team today remember a promise that the padding buffer would be greater than 8.

Do you mean that nobody in the team recalls a promise to application
developers that the padding buffer would be no greater than 8 bytes?

> I would not say that padding is not a concern. There is definitely concern about security vulnerabilities pursuing this course of action.  We have seen plenty of issues with CBC and padding. At the least, if there is a padding oracle then there is a problem. So there will need to be much more scrutiny if moving away from CTS. Remaining with CTS would be preferred as it would both avoid the app compat issue and security concerns. We would hate to have to disable a new cipher suite due to app compat issues or limit it to enlighted applications. 

My understanding is that the encrypt-then-MAC construction eliminates
the known CBC padding oracle attacks.  If someone has evidence to the
contrary, I would like to hear about it.

> I am curious why we aren't just using the same AES-CTS as in the current RFC?

I think the short answer is Suite B requirements and a desire to
conform with current cryptographic best practices.

I believe one goal is to align with
draft-mcgrew-aead-aes-cbc-hmac-sha2.  Earlier proposals for the Suite
B enctypes involved GCM (I think we had a consensus that GCM wouldn't
really work for anything invoving long-term keys), and some variant on
the padded CBC that we're considering now, but changed to CTS mode
because of MS-RPC related padding concerns.  It's a different CTS mode
than the one we use for RFC 3962.

I think part of the justification for the differences between
draft-ietf-kitten-aes-cts-hmac-sha2-01 and RFC 3962 is to align more
closely with cryptographic best practice.  This includes using an
explicit IV (rather than a confounder) and using encrypt-then-MAC.
The RFC 3962 encode-then-encrypt-and-MAC approach has been proven
secure, but I recall that particular security result was far from
obvious to the research community before the publication of the proof.

> Also why SHA 384 instead of 512?

I asked Kelley about this, and he said the Suite B mandate was for 128
bits for lower security, and 192 bits for higher security.  That would
imply SHA-384 (I think HMAC-SHA-256 should be sufficient, but they
want an unequivocal 192 bits of strength).  I don't know why Suite B
doesn't specify AES-192 instead of AES-256 though.  Maybe these
rationales should be included in future revisions.

Nico Williams <nico@cryptonector.com> writes:

> On Wed, Aug 14, 2013 at 5:55 PM, Michiko Short <michikos@microsoft.com> wrote:
>> I am curious why we aren't just using the same AES-CTS as in the current RFC?
>
> The initially proposed AES-CTS-HMAC-SHA-2 enctype didn't confound,
> though it did have a random block prefix.  This is an optimization
> over confounding: we've mostly convinced ourselves that it merely only
> reduces the number of AES block operations required, not the security
> of the whole.  But this meant that we can have ciphertexts that are
> shorter than one block, which CTS cannot handle.

I get the impression that the research community has been somewhat
uncomfortable with the confounder idea, mostly because it's
unfamiliar.

> We then set about using the non-confounded nonce as a source of
> "ciphertext" to steal from.  The result was more complex than the CTS
> we use today, and shares with CTS the general lack of support in
> existing APIs (e.g., PKCS#11).  Tom Yu and others expressed concern
> about this and a preference for plain old CBC with nonces.  Ever since
> we've been wondering if this would be a problem for Microsoft,
> specifically for DCE and SSPI applications.

I think part of the complications were because Kelley wanted all of
the bits of the IV to be included in the MAC.

Re: [kitten] considering abandoning CTS mode (Re:… Michiko Short
Re: [kitten] considering abandoning CTS mode (Re:… Sam Hartman
Re: [kitten] considering abandoning CTS mode (Re:… Michiko Short
Re: [kitten] considering abandoning CTS mode (Re:… Nico Williams
Re: [kitten] considering abandoning CTS mode (Re:… Tom Yu
Re: [kitten] considering abandoning CTS mode (Re:… Kelley Burgin
Re: [kitten] considering abandoning CTS mode (Re:… Nico Williams
Re: [kitten] considering abandoning CTS mode (Re:… Henry B. Hotz
Re: [kitten] considering abandoning CTS mode (Re:… Tom Yu
Re: [kitten] considering abandoning CTS mode (Re:… Henry B. Hotz