Subject: Re: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01

From: "Peck, Michael A" <[email-masked]>
Date: Tue, 1 Oct 2013 13:06:24 +0000

I just uploaded our latest CBC draft.  It's probably awaiting WG chair approval.  It's here temporarily: http://www.ietf.org/staging/draft-ietf-kitten-aes-cbc-hmac-sha2-00.txt
We're obviously happy to follow whatever the WG consensus ends up being for CBC vs CTS.

SHA-384 is in our drafts because it's one of the Suite B hash algorithms.  We'd be happy to add the AES-256 and HMAC-SHA-512 combination too.

I believe there was some prior mailing list discussion about AES-CMAC.  We didn't use it because it only provides 128 bits.

Mike

From: "Paul Miller (NT)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 20, 2013 8:28 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Michiko Short <[email-masked]<mailto:[email-masked]>>
Subject: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01

I should first introduce myself as I am most likely unfamiliar to most of you.  My name is Paul Miller and I am the developer responsible for the Kerberos implementation in Windows.  In addition to working on Kerberos, I also am primarily responsible for the SSPI interface.  Michiko Short is out of office until November; in the interim I will be the Microsoft representative to the working group.  I apologize for the lateness of this communication.

Last month I met with Michiko and our cryptographer Niels Ferguson along with a few other stakeholders to discuss the draft and the possibility of using the CBC cipher mode instead of CTS.  Our conclusion is that the risk of application compatibility when using a cipher suite that does not preserve the length of the cipher text is too high.  Most Windows consumers of SSPI for user authentication call SPNEGO.  This historically negotiates either Kerberos or NTLM.  NTLM uses the RC4 stream cipher which preserves length, while Kerberos between Windows systems would use either RC4 or AES-CTS, both of which are length preserving.  While it is true that most applications do not call into SSPI directly, instead going through a component like RPC that will handle message encryption correctly, even the fraction of applications that call directly still represents thousands of pieces of software.  Of these, a non-trivial percentage are likely not to handle data expansion correctly.  It is true that DES has padding and that as a result callers should handle this correctly, but due to the fact that DES has never been negotiated by default between Windows systems (and is even disabled by default in current versions) means that test coverage of third party applications with DES encryption is essentially non-existent.

Due to the application compatibility risk that we would face, we do not feel that CBC is worth the risk.  CTS is proven to work for our callers.

Here are some other unordered observations from that meeting:

We use CTS today with AES so the complexity penalty for using it is already paid.  Using known-good code reduces the chance of introducing new security holes.

Using SHA-384 serves no purpose.  It’s the same operation as SHA-512 and thus no cheaper to perform.

Alternately, there as AES-CMAC which has the benefit of reusing the AES code and can be accelerated with AES-NI, but it is only 128 bits of output.

I would also offer that CTS is in fact CBC where the padding is cipher text from the second to last block.  The property of this padding where we can then omit the cipher text that is absorbed into the last block of plain text in order to preserve length is orthogonal to the properties of the cipher mode.  I do not see where using the CTS mode would then impact the ability of cryptographic implementations to support AES or the compliance of those implementations with security standards.

Paul J. Miller