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

From: "Paul Miller (NT)" <[email-masked]>
Date: Sat, 21 Sep 2013 00:28:06 +0000

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 Sep 2013 12:42:10 -0400

Hi.
With my chair hat on, does anyone wish to re-open the discussion of the
CBC decision based on this late input?

Josh and I believe that the bar for re-opening the discussion is
relatively low but does require support from more than just Paul.
I have not had a chance to seek Shawn's input on this process question.

However, the bar for reversing our previous decision is higher than if
this message had been received prior to the consensus call.
At this point, the direction of the WG is CBC and we're evaluating
changing directions.
Which of course we can do, but it requires sufficient support from the
group.

Sam hartman
Kitten co-chair.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 23 Sep 2013 17:58:51 -0400 (EDT)

> CBC decision based on this late input?

No comment on that particular question as of yet, but I would ask for a 
clarification from Paul -- when he says that "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.", does this 
account for the difference between the existing enctypes (17,18) and the 
propsed enctypes with respect to the use of a confounder versus explicit 
initialization vector, and the the corresponding need to special-case 
short inputs in the new proposal?  I could not tell what Microsoft's 
position on the short-input behavior was from Paul's initial message.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Mon, 23 Sep 2013 17:52:30 -0500

On Sat, Sep 21, 2013 at 12:28:06AM +0000, Paul Miller (NT) wrote:
> 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.

Some questions:

1) Is this a problem where apps use SSPI incorrectly, or is it more
   general, that SSPI cannot use mechanisms with enctypes with variable
   padding?

2) If the answe to (1) is that it's not a general problem, is it
   specific to MS-RPC or is it more general?

3) What are the failure modes for potentially affected apps?

   Do apps... crash?  or just fail to communicate when the session key
   enctype requires variable padding?

4) What does bad app code look like?
   (so we can understand the issues, so we can spot problem apps)

5) Can the system (SSPI) detect bad apps and work around this problem?
   (by, e.g., negotiating the older CTS enctypes)

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Tue, 24 Sep 2013 14:16:17 +1000

Paul,

In a putative SSPI implementation of RFC 4121 enctypes with padding, would you put the 4121 filler in SECBUFFER_PADDING or in SECBUFFER_TOKEN?

In our scatter-gather implementation in MIT, it looks like:

    /* GSS: -------GSS-HEADER--------+-DATA--+-PAD-+----------GSS-TRAILER----------*/
    /* CFX: GSS-Header | Kerb-Header | Data  |     | EC | E(Header) | Kerb-Trailer */

i.e. the EC goes in the trailer buffer (because I drew a [possibly erroneous] pedantic distinction between 4121-layer filler and 3961-layer padding). That makes for variable length trailer buffers if EC is not fixed (obviously, this is just API semantics).

SSPI has a single token buffer, so you have to use RRC. Would it look like:

    /* SSP: -----------------SSPI-TOKEN-------------------------+-DATA--+-PAD-*/
    /* CFX: GSS-Header | E(Header) | Kerb-Trailer | Kerb-Header | Data  | EC  */

or:

    /* SSP: -----------------SSPI-TOKEN------------------------------+-DATA--+-PAD-*/
    /* CFX: GSS-Header | EC | E(Header) | Kerb-Trailer | Kerb-Header | Data  |     */

i.e. is your compatibility concern that applications can't deal with padding at all, or that they can't deal with variable length tokens, or something else?

cheers,
Luke

---

From: Sam Hartman <[email-masked]>
Date: Tue, 24 Sep 2013 10:41:35 -0400

>>>>> "Benjamin" == Benjamin Kaduk <[email-masked]> writes:

    Benjamin> On Mon, 23 Sep 2013, Sam Hartman wrote:
    >> Hi.  With my chair hat on, does anyone wish to re-open the
    >> discussion of the CBC decision based on this late input?

    Benjamin> No comment on that particular question as of yet, but I
    Benjamin> would ask for a clarification from Paul -- when he says
    Benjamin> that "We use CTS today with AES so the complexity penalty
    Benjamin> for using it is already paid.  Using known-good code
    Benjamin> reduces the chance of introducing new security holes.",
    Benjamin> does this account for the difference between the existing
    Benjamin> enctypes (17,18) and the propsed enctypes with respect to
    Benjamin> the use of a confounder versus explicit initialization
    Benjamin> vector, and the the corresponding need to special-case
    Benjamin> short inputs in the new proposal?  I could not tell what
    Benjamin> Microsoft's position on the short-input behavior was from
    Benjamin> Paul's initial message.

well, I can't think of a way to get to a short-input case throguh SSPI.

It seems like we're having the discussion, so that bar has been reached.

---

From: "Paul Miller (NT)" <[email-masked]>
Date: Tue, 24 Sep 2013 22:00:18 +0000

Through GSS_Wrap, the fact that we are encrypting at least the header per RFC 4121 ensures that the message is not less than one block.  The use of the cipher suite in the context establishment could be a problem, however.

Without the confounder to avoid the short message problem, there could be ambiguity between what is CTS encoded to exact length and what is padded when the cipher text is exactly one block length.  That is to say that the plain texts:

01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd
01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd 01

Would end up encrypting the same and could not be distinguished as the former would need to PKCS #7 pad and the latter would just CBC the single block.

I'm sorry I missed a lot of the context from prior discussions, but what is the reason for using a traditional IV instead of the confounder?  I don't see a difference in security and using the confounder like cipher text allows CTS for short inputs.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Tuesday, September 24, 2013 7:42 AM
To: Benjamin Kaduk
Cc: [email-masked]; Michiko Short; Sam Hartman
Subject: Re: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01

It seems like we're having the discussion, so that bar has been reached.
_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten