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

Simon Josefsson <> Tue, 06 October 2009 13:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A42BF3A691E for <>; Tue, 6 Oct 2009 06:32:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.563
X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H1SxHOQal7cy for <>; Tue, 6 Oct 2009 06:32:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4D5493A67AE for <>; Tue, 6 Oct 2009 06:32:32 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.14.3/8.14.3/Debian-5) with ESMTP id n96DY4vZ005623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 6 Oct 2009 15:34:06 +0200
From: Simon Josefsson <>
To: Paul Hoffman <>
References: <p0624087dc6efe84bcc54@[]>
OpenPGP: id=B565716F; url=
Date: Tue, 06 Oct 2009 15:34:04 +0200
In-Reply-To: <p0624087dc6efe84bcc54@[]> (Paul Hoffman's message of "Mon\, 5 Oct 2009 11\:17\:58 -0700")
Message-ID: <>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Subject: Re: [TLS] New draft: draft-solinas-tls-additional-prf-input-00.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Oct 2009 13:32:34 -0000

Paul Hoffman <> writes:

> 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.

  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
  Implementors may want to provide a mechanism for relaying identity and
  version information similar to the "Vendor ID Payload" used in ISAKMP

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

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.