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

[David-Sarah Hopwood <[e-mail]>]

Eric Rescorla wrote:
> 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.
[...]
>    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 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