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

[Michiko Short <[e-mail]>]

Apologies for the late response, I have not been tracking the crypto discussions on aes-cts-hmac-sha2, so I did not realize a response was needed.

Since the issue which requires the padding is caused by applications that do not use the SSPI APIs correctly, this should not be driver for the new crypto. Windows SSPI functions exist for an application to obtain the required lengths for use with the in-place encryption functions. Performance and security should be the drivers for selection of the new AES algorithm. We do get a lot of feedback about perf.

Thanks,
Michiko Short | Program Manager | Windows Security & Identity



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Wednesday, July 10, 2013 3:42 PM
To: [e-mail]
Subject: Kitten Digest, Vol 104, Issue 5



Today's Topics:

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

Message: 1
Date: Wed, 10 Jul 2013 16:30:46 -0500
From: Nico Williams <[e-mail]>
To: Tom Yu <[e-mail]>
Cc: [e-mail]
Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action:
	draft-ietf-kitten-aes-cts-hmac-sha2-01.txt)
Message-ID:
	<CAK3OfOiqmJ=[e-mail]>
Content-Type: text/plain; charset=UTF-8

On Tue, Jul 9, 2013 at 6:46 PM, Tom Yu <[e-mail]> wrote:
> I've looked at the diff against the previous version of this document.
> Most of the changes look reasonable to me, but the special case 
> handling of short plaintexts seems too complicated from an 
> implementation perspective.  I'd prefer to go back to the more widely 
> accepted practice of CBC mode with explicit IV and PKCS#7-ish padding.
>
> It seems that one of the goals of this effort is to use, as much as 
> possible, the off-the shelf capabilities of cryptographic modules that 
> are validated to FIPS 140-2 or other relevant standards.  As far as I 
> know, few (if any) validated cryptographic modules support CTS mode 
> directly.
>
> At this point, I think it is useful to try moving away from CTS: the 
> benefits of CTS do not outweigh the implementation complexity, 
> particularly when dealing with the short plaintext case.  Implementing 
> CTS mode has already proven to be a challenge even for the existing 
> AES-CTS enctypes, and I'm reluctant to magnify that difficulty with 
> the new enctypes in this document.  Returning to a scheme based on 
> conventionally padded CBC would further the goal of using the existing 
> capabilities of validated cryptographic modules, and poses fewer 
> implementation risks.

I'm not at all worried about implementation risks.  We can test every possible plaintext length between the shortest (zero-bytes) and a small multiple of the block size (in bytes), both with test vectors and random data (making sure it round-trips).

I think the only risk we should be concerned about here is the risk that we might design-in a cryptographic weakness.  I definitely don't want to be even partly to blame for that :) so it's a risk that bothers me.  I think we can analyze the non-confounded CTS we came up with, and we could/should/must ask for review by strong cryptographers before we go forward with it (or otherwise we must show that the new thing must have the same properties as the old confounded CTS, which I think we informally did, but we'd have to redo that analysis).

Another risk I care about is the risk that we lose some hardware optimizations as a result of using CTS.  Though with the trend towards on-die hardware cipher implementations that problem becomes much less relevant.

> Statements from Microsoft imply that the main problems caused by 
> variable-length ciphertext expansion would be limited to SSPI 
> applications that do not use the APIs correctly.  SSPI functions exist 
> such that an application can use to obtain the required lengths for 
> use with the in-place encryption functions.

This was a big deal to them once.  It might still be.  It'd be nice to hear from someone at Microsoft as to whether this is still an issue.

> I realize we've spent a significant amount of effort trying to make 
> CTS work in the short-plaintext case.  I'd like to thank to Nico, 
> Kelley, and others who participated in trying to make CTS mode work in 
> this specification.  Looking at this document as an implementer, I 
> think using CTS mode, especially with the short-plaintext special 
> case, presents too much risk, and I'd like us to consider going back 
> to a more normal CBC mode.

I'll be fine with ditching the no-padding requirement if the implementors we've known to care for no-padding modes are ok with it now and no new ones show up to tell us otherwise.

Nico
--