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

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Oct 2013 15:53:43 -0400

>>>>> "Paul" == Paul Miller (NT) <[email-masked]> writes:

    Paul> While I agree with the analysis that the use of a confounder
    Paul> will limit the exposure of the state of a faulty PRNG, I don't
    Paul> see this as a problem that needs to be addressed by Kerberos.
    Paul> The RNG is a system service and not part of the Kerberos
    Paul> specification.  RFC 4120 references RFC 4086 "Randomness
    Paul> Requirements for Security" so the condition not to use a PRNG
    Paul> that leaks state is already covered.  Between nonces and
    Paul> randomly generated session keys, there are plenty of other
    Paul> avenues for insufficient randomness to manifest.  This is not
    Paul> to say that I disagree with using a confounder.  A confounder
    Paul> is quite useful as a source of cipher text from which to steal
    Paul> in order to make CTS work with short inputs.

The issue here in my mind is that it seems like we as a community have
paid inadequate attention to what the damage of a malicious RNG could do
is.  We've been focusing on the sorts of things described in RFC 4086,
rather than RNGS maliciously affected either in implementation or
standards.

That class of attack having been pointed out, we should consider its
impact on security systems we design.

I agree that introducing another covert channel by which random data can
leak is kind of uninteresting.

However, an attacker who can predict your RNG state will now be much
more able to predict future explicit IVs.
Where as that attacker will find it difficult to predict explicit
confounders without knowing the key.

I have not yet figured out whether this matters.

---

From: Nico Williams <[email-masked]>
Date: Tue, 1 Oct 2013 17:19:31 -0500

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