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

<> Mon, 26 October 2009 08:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 33A9B3A67D4 for <>; Mon, 26 Oct 2009 01:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.579
X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tSuYG0R3EZWB for <>; Mon, 26 Oct 2009 01:11:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 681BE3A6774 for <>; Mon, 26 Oct 2009 01:11:12 -0700 (PDT)
Received: from ( []) by (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9Q8BGQ9004131; Mon, 26 Oct 2009 10:11:21 +0200
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:11:17 +0200
Received: from ([]) by over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:11:02 +0200
Received: from ([]) by ([]) with mapi; Mon, 26 Oct 2009 09:11:02 +0100
Date: Mon, 26 Oct 2009 09:11:00 +0100
Thread-Topic: [TLS] New draft: draft-solinas-tls-additional-prf-input-00.txt
Thread-Index: AcpGibwe1Ckmr7tbRC+TSHgMIBNTmAPh1z4g
Message-ID: <>
References: <p0624087dc6efe84bcc54@[]> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Oct 2009 08:11:02.0312 (UTC) FILETIME=[DBA8CA80:01CA5613]
X-Nokia-AV: 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: Mon, 26 Oct 2009 08:11:14 -0000

I agree with Simon here that in the minimum, the extension should have
a "type" field to ensure that if the recipient parses the information,
it's using the same format as the sender. (Some other protocols use
the Enterprise Number registry for "vendor specific" payloads, instead
of creating a new FCFS registry.)

However, I'd like to re-iterate my earlier concern about the original
draft-rescorla-tls-opaque-prf-input draft: this defines a basically
general-purpose extension mechanism to TLS.

We already have a well-defined extension mechanism for TLS (TLS
extensions), which would allow people to do exactly the sorts of
things envisioned in Section 1.1. Its only "drawback" is that it
requires going through the IETF process to obtain the IANA allocation,
and thus publicly documenting what you're doing.

The main "feature" of this draft seems to be allowing "interesting"
extensions without going through the IETF process, or even publicly
documenting what you're doing.  I can certainly see that folks at NSA
might be interesting in doing exactly such things, and they could have
(in their opinion) good reasons.  And some other IETF protocols do
indeed allow pretty much unlimited vendor extensibility (by e.g.
allowing "Vendor Specific" payloads anywhere).

But if the WG decides that adding such extensibility to TLS is a good
idea, I would predict that many folks will use this mechanism to
define new TLS extension so that they can avoid the somewhat
time-consuming process of consensus-building and standardization.

Many of the existing TLS extension could have been done by specifying
suitably "structured" PRF inputs: client/server_authz, user_mapping,
trusted_ca_keys, server_name, status_request, etc. (In these cases,
it doesn't really matter if the input gets fed to PRF; the interesting
part is adding a free-form payload to ClientHello/ServerHello without
requiring an extension number from IANA.)

I know sevaral people have occasionally been frustrated that it's very
difficult to extend TLS (since the requirements for IANA allocation
are quite strict). Personally, I view this as a feature, and I think
it has contributed to general interoperability of TLS/SSL -- it's
generally viewed as a protocol that "just works" (compared to some
other protocols which have large numbers of optional extensions, and
it's very difficult to get implementations from different vendors
to interoperate).
Best regards,
(not wearing any hats)

> -----Original Message-----
> From: [] On Behalf Of
> ext Simon Josefsson
> Sent: 06 October, 2009 16:34
> To: Paul Hoffman
> Cc:
> Subject: Re: [TLS] New draft: draft-solinas-tls-additional-prf-input-
> 00.txt
> Paul Hoffman <> writes:
> >>
> 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
> _______________________________________________
> TLS mailing list