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

[Eric Rescorla <[e-mail]>]

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?