Re: [TLS] New draft: draft-solinas-tls-additional-prf-input-00.txt

[Simon Josefsson <simon at josefsson.org>]

Paul Hoffman <paul.hoffman at vpnc.org> writes:

>>http://www.ietf.org/internet-drafts/draft-solinas-tls-additional-prf-input-00.txt
>
> Greetings again. We would like to hear input on this draft from the
> TLS community. The basic idea is an extension that would allow the two
> parties to give additional information that is directly mixed into the
> master secret through the PRF.

The document seems fine to me.

As far as I can tell, any implementation (including mine) of
draft-rescorla-tls-opaque-prf-input-00.txt would be compatible with
draft-solinas-tls-additional-prf-input-00.txt, and that is good.

The two last examples in section 1.1 doesn't appear fully baked to me.
Quoting:

  TLS servers may arrange for their clients to provide authentication
  data early in the protocol (such as an HMAC value computed over a
  fresh random value using a shared secret as the key) in order to
  authenticate the client as a member of a private network or as an
  additional means of mitigating the impact of a denial-of-service
  attack.
				
  Implementors may want to provide a mechanism for relaying identity and
  version information similar to the "Vendor ID Payload" used in ISAKMP
  [RFC2408].

If these use-cases are intended to be realistic use-cases of the
extension (which doesn't seem clear to me), I believe the document needs
more work: it should suggest a structure of the PRF data so that servers
will understand what type of data the client sent.  Compare for example
how RFC 5077 suggests a format.  The document could even go further and
mandate a particular format, which would make the use-cases more likely
to interoperate, such as:

     enum {
         entropy(0), (65535)
     } AdditionalPRFInputType;

     struct {
         AdditionalPRFInputType type;
         opaque value<0..2^16-1>;
     } AdditionalPRFInput;

     AdditionalPRFInput prfinputs<2..2^16-2>;

The AdditionalPRFInputType could be a FCFS registry.  The intention with
the "entropy" field is that it should contain random data with no
intended meaning, which appears to be the typical use-case.  Other types
can be allocated to signal the two use-cases in the example if/when
needed.

Alternatively, and considering the complexities in my proposed change, I
would suggest that you remove other use cases than the one to provide
additional entropy to the MS key computation and say that there is only
one intended use-case for this extension.  If other use-cases of the
extension are important, they can be described in separate documents.

Thanks,
/Simon