Subject: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00

From: Sam Hartman <[email-masked]>
Date: Tue, 14 May 2013 15:45:34 -0400

Overall:

I think this is in fairly good shape. My comments seem to mostly fall
into two categories:

1) As chair I'm requesting that this document make no reference to
terminology or concepts introduced in the simplified profile in RFC
3961.
For the most part I'd expect this spec to refer only to RFC 3961
sections 3 and 4.

2) I recommend that the editors minimize references to RFC 3962; in
general repeating text from RFC 3962 is probably better than references.
This is a recommendation, not a requirement for progression; if the
editors consider the issue and believe that some references to RFC 3962
improve clarity or minimize the probability of specification or
implementation error, I'll be happy with that.

Detailed comments:

section 4:

The salt input to string_to_key is not under the control of a
specification of an RFC 3961 enctype.
It's inappropriate to place restrictions on the salt in this
specification.
Operationally what you may want is to encourage KDCs to include 128-bits
of randomness in the salt they use.
That doesn't belong as part of the encryption type specification; it may
be appropriate in the same document, clearly separated.

However, I think there are some issues related to keying services that
tend to come up if the salt contains random data. I know the MIT folks
explored this; I don't remember all the conclusions.

If this property is important, you'll almost certainly want to explore
advantages attackers could gain by causing a client to use the default
Kerberos salt--that is, just the principal and realm.  If we don't end
up liking the implications of that analysis we'll need to look at
changes broader in scope than are appropriate for an enctype
specification.

Section 5:

You seem to be using the function dr(), defined as part of the
simplified profile in RFC 3961, but your definition is different than
that in RFC 3961.  I find this notation confusing and would recommend
against adopting notation from the simplified profile.

Similarly, calling the key usage input to the key derivation n is
notation from the simplified profile, not from section 3 of RFC 3961 and
is highly confusing.

section 6:

The use of notation from the simplified profile is really problematic
here.

I think using cE, D and m is fine. I just think it would be desirable to
define them yourself rather than referencing the simplified profile
definitions.

I think I'd like to hear responses to these comments before deciding
whether we're ready for working group last call.

---

From: Greg Hudson <[email-masked]>
Date: Tue, 14 May 2013 19:00:26 -0400

I have an additional comment:

Section 6 notes that "[SP800-38A+] requires the plaintext length to be
greater than or equal to the block size" but gives no guidance on what
to do if the input is smaller than that.  This seems like a pretty
serious problem.

The RFC 3962 enctypes do not have this problem because they use a
confounder, which adds a block of input.  They did have to specify what
to do when the input length is 0, such that the cipher plaintext is
exactly one block.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 14 May 2013 19:32:22 -0400

>>>>> "Greg" == Greg Hudson <[email-masked]> writes:

    Greg> I have an additional comment: Section 6 notes that
    Greg> "[SP800-38A+] requires the plaintext length to be greater than
    Greg> or equal to the block size" but gives no guidance on what to
    Greg> do if the input is smaller than that.  This seems like a
    Greg> pretty serious problem.

    Greg> The RFC 3962 enctypes do not have this problem because they
    Greg> use a confounder, which adds a block of input.  They did have
    Greg> to specify what to do when the input length is 0, such that
    Greg> the cipher plaintext is exactly one block.

Thanks.  Yeah, I had missed this item because I was thinking there would
be a confounder, but that's not how the nonce is handled.

---

From: Nico Williams <[email-masked]>
Date: Mon, 20 May 2013 15:10:52 -0500

> to do when the input length is 0, such that the cipher plaintext is

I agree, this needs to be resolved.

It also makes me wonder why no confounder.  I don't think we must have
confounders (or CTS), and I'd not insist on having them, but I'm
curious as to why not keep using confounders.  So far my best guess is
that confounding increases the *plaintext* size (not just the
ciphertext), and this might cause performance problems in some
hardware-assisted implementations.

I'm not sure what, if anything, we lose by having an IV instead of a
confounder.  Eavesdroppers get to see the IV, but not the confounder's
plaintext, and this presumably leaks some information about the
sender's entropy, but it's not clear that we should care, since we
assume [and very much depend on having] a decent enough [P]RNG with
decent enough seeding [in the PRNG case].  Active attackers also get
to modify the IV, but they get to modify the confounder, and any other
bit of ciphertext and so on, so this is not an issue.

As for what to do when the input is shorter than a full ciphertext
block, there are some options.  The two most obvious ones are: pad, or
confound.  My preference would be to confound in this case.  Kerberos
itself never really needs to encrypt plaintexts shorter than 128 bits
today, IIRC, but the GSS mechanism has to support shorter plaintexts,
and Kerberos may have to some day for all we know.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 20 May 2013 16:31:31 -0400

> and Kerberos may have to some day for all we know.

RFC3961 also gets used by other protocols, both within and outside the
IETF.  Some of these do or may include plaintexts shorter than 16 bytes,
so IMHO, failing to deal with such short plaintexts is definitely a
problem.

-- Jeff