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

[Nico Williams <[e-mail]>]

On Fri, Oct 4, 2013 at 9:17 AM, Greg Hudson <[e-mail]> 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
--