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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88BCD11E81C4 for <>; Wed, 14 Aug 2013 20:26:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Cb79Bf3T4fcl for <>; Wed, 14 Aug 2013 20:26:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BD50311E80F6 for <>; Wed, 14 Aug 2013 20:26:29 -0700 (PDT)
X-AuditID: 1209190f-b7fa58e000000953-b5-520c4a64bc5c
Received: from ( []) by (Symantec Messaging Gateway) with SMTP id CB.27.02387.46A4C025; Wed, 14 Aug 2013 23:26:28 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id r7F3QRHu028741; Wed, 14 Aug 2013 23:26:28 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id r7F3QP8d000315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Aug 2013 23:26:26 -0400
Received: (from tlyu@localhost) by ( id r7F3QPYc006477; Wed, 14 Aug 2013 23:26:25 -0400 (EDT)
To: Michiko Short <>
References: <> <> <> <>
From: Tom Yu <tlyu@MIT.EDU>
Date: Wed, 14 Aug 2013 23:26:24 -0400
In-Reply-To: <> (Nico Williams's message of "Wed, 14 Aug 2013 18:57:28 -0500")
Message-ID: <>
Lines: 69
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42IR4hRV1k3x4gkyuL3IxOJr2wM2i6ObV7FY /Ovmszh17QibA4vHy1PnGD2WLPnJ5NG64y+7x8qpp9kDWKK4bFJSczLLUov07RK4Mtp/XmIu eChXsX7uPrYGxs8SXYycHBICJhKth/azQNhiEhfurWfrYuTiEBLYxyjxsukqC4SzkVHi94Gt TCBVQgLnmCTe3q2FSHQxSux5to4dJCEioCXx4cJpsFHMAjUS7f9uM4PYwgKFEh8ObWaBaJ7F JLH8t20XIwcHm4C0xNHFZSBhFgFViSdLvjKC2JwCExglDi7gBrF5BSwktnz4ABbnEeCUmPf2 NQtEXFDi5MwnUKu0JG78e8k0gVFwFpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3RN 9HIzS/RSU0o3MYLDWZJ/B+O3g0qHGAU4GJV4eCPauIOEWBPLiitzDzFKcjApifLae/IECfEl 5adUZiQWZ8QXleakFh9ilOBgVhLhjdEGyvGmJFZWpRblw6SkOViUxHmfPT0bKCSQnliSmp2a WpBaBJOV4eBQkuCdAzJUsCg1PbUiLTOnBCHNxMEJMpwHaPhGkBre4oLE3OLMdIj8KUZdjj8r 535iFGLJy89LlRLnXQVSJABSlFGaBzcHloZeMYoDvSXM2wFSxQNMYXCTXgEtYQJa4pDNBbKk JBEhJdXAaP9cx4S5T6loURjfF/fNNx+83Lzr/ckz4aac734vvcNRpKX+uqzhzTUDZgbO4l87 7+xRm7ddfsGp5pQV71VEHncr2WT+f5oTO11rb+Pb2TwrvsrxiG3dIXd4xZmYJxOvefxSE3JW znl4lVfd97EsC9uD2XHfw7bGcd7YP02302JPWIuSQkguoxJLcUaioRZzUXEiAJe74T0eAwAA
Cc: "" <>, Sam Hartman <>
Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action:draft-ietf-kitten-aes-cts-hmac-sha2-01.txt)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Aug 2013 03:26:36 -0000

Michiko Short <> 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 <> writes:

> On Wed, Aug 14, 2013 at 5:55 PM, Michiko Short <> 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

> 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.