Subject: [TLS] Comments on draft-solinas-tls-additional-prf-input

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Nov 2009 13:17:08 +0100

Despite not being clear on what this is for, I don't have a problem
with there being a code point assigned for this extension for USG use. 
However, I don't think that some of the proposed uses are in
fact appropriate and would like to see the document revised accordingly.

In particular, there are two potential things one might be trying
to do here:

1. Add additional randomness into the PRF.
2. Add structured, meaningful data into the PRF.

AFAICT, the first of these is useless but harmless: useless because
the security guarantees of TLS require only uniqueness of the 
Random values, not unpredictability, and 28 bytes is far more than
required to provide a statistical guaranteee of uniqueness; harmless
because the PRF can easily absorb additional new data, even if it
is completely nonrandom. 

The second, however, is a backdoor method of extending TLS and the
semantics are completely different: in order to be useful, the
data in the extension must be processed and potentially checked
by the other side. Several mechanisms for extending TLS already
exist (TLS Extensions and then the TLS Supplemental Data
message) and should not add yet another generic mechanism 
here.

I don't have a problem with an opaque field here, since that's
really just a private code point assignment. But having it
have actual semantics leaks into TLS and I do object to that.

DETAILED COMMENTS
S 1.
   The mechanism described here has several desirable features which may
   prove useful beyond the requirements of the US Government
   applications.  It is easy to implement, and using it adds little to
   the overall computation of the TLS handshake.  Further,
   interoperability is preserved between clients that implement the
   extension and servers that do not, and between clients that do not
   implement the extension and servers that do.

These really aren't generically desirable features, since they
just say "this doesn't do any damage".  I guess that's desirable,
but the relevant quesiton is why one would want to do this at all.

S 1.1.
   Several recommendations for key derivation call for the concatenation
   of additional information fields into the key derivation function
   when producing a shared key.  For example, the specification of
   Alternative 1 in NIST Special Publication 800-56A ([SP800-56A]) calls
   for the inclusion of "OtherInfo" fields.  In this case, OtherInfo
   contains the concatenation of a variety of mandatory and optional
   sub-fields.  The extension described in this document provides a
   simple mechanism both for supplying the public information to the
   peer and for the inclusion of the information in the key derivation.
   Many other application environments require or allow similar fields.

This actually seems extremely dangerous. AFAICT the point of these
OtherInfo fields is that they are explicitly bound into the PRF
on both sides. In order to be useful (as opposed to formally present),
OtherInfo needs to be explicitly produced/verified by each side.
This needs to be removed.

S 3.1.
   The AdditionalRandom type, whose AdditionalPRFInputType value is
   {TBD1}, is used to add additional random values from the client
   and/or the server to the PRF.  The size and the contents of the
   AdditionalPRFInputValue are undefined (other than it must be between
   0 and 2^16-4 bytes).  The size of the AdditionalPRFInputValue
   provided by the client does not indicate anything about the expected
   size of the AdditionalPRFInputValue from the server.

So there is no way for the client to elicit a certain amount of 
additional random data from the server?

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 12 Nov 2009 05:07:27 +0000

> message) and should not add yet another generic mechanism 
[...]
> but the relevant question is why one would want to do this at all.

I agree. The gist of any discussion of rationale seems to be basically:
"The U.S. Government has these special requirements that you wouldn't
understand. Since they're a government, they needn't explain themselves,
and we're not going to explain either."

One possible reason why you might want to cause a handshake failure
for clients and servers that fail to agree on the 'additional input',
is to avoid cross-protocol attacks, i.e. to prevent a session that
is supposed to be using one protocol from being misinterpreted as using
another. I'm not convinced that this extension is the simplest or most
effective way of doing that, though.

In the descriptions of 'OtherInfo' in
<http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf>,
it seems that one intended usage is to prevent confusion about which
identities are participating in the key exchange (for example "At a
minimum, PartyUInfo shall include ID_U, the identifier of party U.",
on PDF page 46). In TLS that's unnecessary because any certificates
are included in the Finished hashes.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 13 Nov 2009 11:32:14 -0600

> 2. Add structured, meaningful data into the PRF.

3. Add channel binding to other channels (for TLS, outside
   re-negotiation, this is extremely unlikely; no one is likely to care
   about TLS-to-IPsec channel binding for many years to com)

4. Provide integrity protection to application-layer negotiations that
   precede the TLS handshake.  Think of the "StartTLS" pattern in a
   large variety of protocols, including LDAP and HTTP (as opposed ldaps
   and https), where one might want to protect any pre-starttls
   negotiations (possibly by hashing pre-starttls messages and using
   them as the additional input).

5. Prove that out-of-band data (other than the type described in (4)) is
   the same on the client and server sides.

There may be others.

Examples of (3) and (4) exist.  Example of (3): SCRAM uses channel
binding.  Example of (4): SASL/GS2 uses the GSS-API channel binding
facility to protect data sent outside GSS-API context tokens.  Another
example of (4): a recent addition to OpenSolaris, a remote audit
protocol, uses the GSS-API channel binding facility to protect
application protocol version negotiation.

(3) may well be useless in TLS, outside the context of re-negotiation
anyways (where your fix is, effectively, to add a non-generic channel
binding from the inner to the outer connection).

(4) is, IMO, incredibly useful.  Paul seemed to misunderstand me the
other day and cut me off before I could explain that a channel binding
facility is not _only_ about channel binding, that there are uses for
such a thing that are not actually channel binding.

I have no examples of (5).  In very specific cases it may be useful.
(5) could also be used as a way to add a PSK-like component to TLS, but
one would have to be careful about how to identify a key for that.

> because the PRF can easily absorb additional new data, even if it

Agreed.

> message) and should not add yet another generic mechanism 

You might argue that (4) is like (2), but then you'd also be saying that
the StartTLS pattern is a "backdoor method of extending TLS".  One might
see StartTLS as such a thing, but that ship has sailed.  I think (4) is
reason enough to have this feature in TLS.

You might argue that (3) will be useless (as I explained).  And you
might argue that (5) is dangerous or undesirable.  Even if we all were
to agree about (3) and (5), we'd still have (4).

> have actual semantics leaks into TLS and I do object to that.

I don't agree.  See above.

I do, however, have comments on the mechanics of this extension, but
I'll leave those for another day.

> This needs to be removed.

Agreed.

Nico
--