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

From: Michiko Short <[email-masked]>
Date: Thu, 8 Aug 2013 22:02:08 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 10, 2013 3:42 PM
To: [email-masked]
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 <[email-masked]>
To: Tom Yu <[email-masked]>
Cc: [email-masked]
Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action:
	draft-ietf-kitten-aes-cts-hmac-sha2-01.txt)
Message-ID:
	<CAK3OfOiqmJ=[email-masked]>
Content-Type: text/plain; charset=UTF-8

On Tue, Jul 9, 2013 at 6:46 PM, Tom Yu <[email-masked]> 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
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Aug 2013 12:21:42 -0400

>>>>> "Michiko" == Michiko Short <[email-masked]> writes:

    Michiko> Apologies for the late response, I have not been tracking
    Michiko> the crypto discussions on aes-cts-hmac-sha2, so I did not
    Michiko> realize a response was needed.  Since the issue which
    Michiko> requires the padding is caused by applications that do not
    Michiko> use the SSPI APIs correctly, this should not be driver for
    Michiko> the new crypto. Windows SSPI functions exist for an
    Michiko> application to obtain the required lengths for use with the
    Michiko> in-place encryption functions. Performance and security
    Michiko> should be the drivers for selection of the new AES
    Michiko> algorithm. We do get a lot of feedback about perf.

So, when were the padding length functions introduced?
I seem to recall that MSDN used to say that the padding buffer would
never be greater than 8.
Am I misremembering?
Is that no longer a concern?

---

From: Michiko Short <[email-masked]>
Date: Wed, 14 Aug 2013 22:55:29 +0000

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

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. 

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

Also why SHA 384 instead of 512?

Thanks,

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Wednesday, August 14, 2013 9:22 AM
To: Michiko Short
Cc: [email-masked]
Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action:draft-ietf-kitten-aes-cts-hmac-sha2-01.txt)

So, when were the padding length functions introduced?
I seem to recall that MSDN used to say that the padding buffer would never be greater than 8.
Am I misremembering?
Is that no longer a concern?

---

From: Nico Williams <[email-masked]>
Date: Wed, 14 Aug 2013 18:57:28 -0500

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

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.

Nico
--

---

From: Tom Yu <[email-masked]>
Date: Wed, 14 Aug 2013 23:26:24 -0400

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

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.

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

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

---

From: Kelley Burgin <[email-masked]>
Date: Thu, 15 Aug 2013 13:28:38 -0400

Thanks Tom for your responses, you are correct.

> contrary, I would like to hear about it.

This is correct.

> conform with current cryptographic best practices.

Correct again.

> than the one we use for RFC 3962.

GCM will not work in a long-term key environment because of counter rollover issues.

> rationales should be included in future revisions.

This encryption type is intended to support Suite B applications.

---

From: Nico Williams <[email-masked]>
Date: Thu, 15 Aug 2013 12:34:40 -0500

> GCM will not work in a long-term key environment because of counter rollover issues.

It can be made to work by using a large enough IV from which to derive
a sub-key for encryption and an IV for GCM itself.  This, of course,
would be sub-optimal: it'd increase ciphertext size (by the additional
IV bits) and it'd add key derivation and key setup costs.  It'd also
depend on having strong-enough sources of entropy, good enough clocks,
and so on, with which to ensure non-reuse of {long-term key, IV}.

With lots of care a 128-bit IV could be used safely, but makes me very
uncomfortable: some implementations/deployments will fail to be
careful enough.

In short: I agree, GCM is out.  Would that we had high-performance
AEAD cipher modes without the IV-reuse-destroys-security problem.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 16 Aug 2013 17:31:32 -0700

> rationales should be included in future revisions.

There was some post on saag about AES-256 now being only 119-bits effective strength?  I confess I never backtracked the source material.  The problem didn't affect AES-128 and AES-192 much less.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Tom Yu <[email-masked]>
Date: Sat, 17 Aug 2013 00:08:54 -0400

> There was some post on saag about AES-256 now being only 119-bits effective strength?  I confess I never backtracked the source material.  The problem didn't affect AES-128 and AES-192 much less.

I'm pretty sure those are related-key attacks, and also affect
AES-192.  They mostly affect the use of AES as a hash function.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 19 Aug 2013 11:52:45 -0700

I was unclear.  It affected AES-192, just much less.

On Aug 16, 2013, at 5:31 PM, "Henry B. Hotz" <[email-masked]> wrote:

> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten