Re: [kitten] explicit CBC IVs vs confounders: covert channels (draft-ietf-kitten-aes-cts-hmac-sha2)

[Nico Williams <[e-mail]>]

For uses of RFC3961 without state chaining there's no way to prove
that the confounder was obtained by encrypting a random IV...  So
confounding isn't necessarily sufficient to prevent leaking of RNG
state or keys, at least not for GSS mechanism uses.  And even where
chaining is used, there is one initial state case where the sender
might not have produced a confounder by encrypting a random IV, so
confounding does little to prevent leakage of RNG state (or outright
leakage of keys) via the confounder.

In light of recent events, I would like us to design protocols that
-as much as possible- have no public nonces, and where they are
necessary, they should be as small as possible and their cryptographic
purpose replaced/augmented by the plaintext of nonces sent enciphered
as soon as appropriate key material is available.  For Kerberos this
may require a revamp of RFC3961, with attendant changes to
implementations' APIs and to applications (so they may use the new
enctypes), unless we get clever.  If we're not prepared to do either
(upate RFC3961 or get clever) at this time, then which I think I
prefer to stick to confounding, with the security considerations
involved noted.

Of course, the right thing to do is to not leak RNG outputs by using
them as random IVs directly.  As various participants have pointed out
in various crypto lists, we all assumed no one would do *that* (use a
conjectured-backdoored RNG's outputs directly as nonces and keys), and
this sentiment will be even stronger going forward.  Preventing peers
from compromising one's communications with them is desirable, but I
think the best we can do is limit their covert channels for doing so,
and since one must trust one's peers to a fairly large degree... I'm
not too concerned here and I'm willing to settle for either random IVs
or confounders if there's no support for doing something better.

Nico
--