Re: [kitten] Input on Paul's concerns about aes-cbc

I don't have any information about specific application failures with padded ciphers.  If there were problems with a block cipher, it would not be possible to do a fallback just for impacted callers as the cipher of the subsession key is chosen during the context establishment which is before the first call to EncryptMessage (GSS_Wrap analogue).  By the time we knew that the caller was not providing for padding, it would be too late to select differently.

With the existing calling pattern used for DES in Windows, callers that did not pass in the SECBUFFER_PADDING into the EncryptMessage call would just fail when the buffer was not aligned.  Additionally, if the buffer was a multiple of the block size then it would not get the PKCS#7 padding and then would fail on the other end that expected the pad block.  I suspect this would break a whole lot of callers.

To reduce the application compatibility problem, I'd have to use the Rotate Right Count in the header to move padding into the header.  Up front, Kerberos on Windows would tell callers that they needed to allocate for the header one block more than they actually need.  Then, on output we would shorten the length to whatever portion was actually used.  This would fix the callers that do not handle padding for the first encryption, but making the header variable length causes a different set of problems.  Today, the header is always the same length so the caller can allocate that buffer and then reuse it throughout multiple encryption calls.  Making it variable length would require the caller to take the additional step of resetting the length field to the allocated size between calls, which not all applications may be doing today.

There are several reasons that I think this is a significant risk.  First of all, the documentation that Microsoft has for the EncryptMessage function for Kerberos has very little bearing on how the function should actually be used.  In fact, most of the document is incorrectly copied and pasted from SSL's documentation.  It'd be highly optimistic to expect developers to have used the API correctly while the documentation was incorrect.  This makes the risk that some application is broken quite high.

The second factor is that we only have the ability to control supported encryption types at the machine level.  This means that if there is one application in an enterprise, all impacted machines will have the new cipher supported.  This means that if a LOB app is  impacted, the enterprise is likely to disable the new cipher on all machines via policy.

If the problem is likely to occur and the impact of the problem is the disablement of the new ciphers for the entire realm, the objective of introducing the new cipher is compromised.  It is much safer to move forward with a cipher that is more likely broadly to be used.

-----Original Message-----
From: kitten-bounces@ietf.org [mailto:kitten-bounces@ietf.org] On Behalf Of Nico Williams
Sent: Friday, October 4, 2013 2:10 PM
To: Greg Hudson
Cc: kitten@ietf.org; Sam Hartman
Subject: Re: [kitten] Input on Paul's concerns about aes-cbc

On Fri, Oct 4, 2013 at 9:17 AM, Greg Hudson <ghudson@mit.edu> wrote:
> On 10/04/2013 09:48 AM, Sam Hartman wrote:
>>
>> 1) Do you need any additional information to evaluate Paul's message?
>
> I don't think so.  We are still curious about the details of legacy 
> application risk (i.e. what kinds of things might a legacy SSPI 
> application do wrong such that it works now but fails with a padded 
> enctype), but the conclusion is pretty clear.

I can't tell if Paul is acting out of [quite reasonable] conservatism, or if he's really identified actual failure modes of existing applications (or likely ones), nor has he indicated whether there's any way to work around such failures (by, e.g., downgrading to CTS enctypes), nor whether any such workarounds are acceptable.

I'm not going to insist on -say- proprietary evidence.  Indeed, I like the random IV CTS mode we cooked up.  I just think we need to understand the *actual* constraints, in so far as they can be published, so that we can a) not have this conversation again later,
b) understand how those constraints might apply to future proposals,
c) document how developers should write code so as not to impose these constraints on us.

> I have also spent some more time thinking about CTR mode as you 
> suggested earlier (where we pick a random 128-bit nonce and use some 
> function f(nonce,
> blocknum) to produce the counter for each block), and whether a nonce 
> or block counter collision is any worse than a CBC cipher-block 
> collision.  I noted that a CTR nonce collision would leak the XOR of 
> the entire plaintexts of two multi-block messages, while a CBC 
> cipher-block collision or only leaks the XOR of the plaintexts of the 
> two colliding blocks, and a CBC IV/confounder collision only leaks 
> information about how many blocks of two messages are identical.

I'm now convinced that what we need in order to make certain cipher modes usable in Kerberos is a change to RFC3961 so that the API knows whether a given key is a sub-session key or not.  I don't feel comfortable with CTR modes applied to long-term keys (or even Ticket session keys) without taking steps that would effectively kill performance for the GSS mechanism's per-msg tokens.  I don't think we should have *this* discussion in the context of CTS vs. CBC: we should first decide that we don't want either CTS nor CBC.

Nico
--
_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten