Re: [TLS] Updated TLS 1.2 I-D

Bodo Moeller <> Mon, 26 June 2006 09:55 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1Funol-0001MT-KZ; Mon, 26 Jun 2006 05:55:43 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1Funok-0001MO-J2 for; Mon, 26 Jun 2006 05:55:42 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1Funoj-0007Ug-7A for; Mon, 26 Jun 2006 05:55:42 -0400
Received: from [] (helo=tau.invalid) by (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1FunoQ3RXb-0002Rr; Mon, 26 Jun 2006 11:55:35 +0200
Received: by tau.invalid (Postfix, from userid 1000) id 39AB019530; Mon, 26 Jun 2006 11:55:22 +0200 (CEST)
Date: Mon, 26 Jun 2006 11:55:22 +0200
From: Bodo Moeller <>
To: Eric Rescorla <>
Subject: Re: [TLS] Updated TLS 1.2 I-D
Message-ID: <>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.9i
X-Provags-ID: login:2100a517a32aea841b51dac1f7c5a318
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
X-Mailman-Version: 2.1.5
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: <>, <>

On Sun, Jun 25, 2006 at 09:54:30AM -0700, Eric Rescorla wrote:

> The big thing I know is misisng is replaceable PRFs, which
> I wanted to discuss on the mailing list before I put in.
> As people will recall, there was a consensus on replaceable
> PRFs/KDFs in Dallas but we didn't discuss exactly how to do
> them.
> My proposal is as follows:
> - All PRFs must have the same "API" as the existing TLS 
>   PRFs.
> - New cipher suites MAY have as part of their specification
>   a new PRF.
> - There is no way to separately negotiate a new PRF for
>   an existing cipher suite.
> The major alternative is some kind of extension, which makes
> me uncomfortable. 
> Thoughts? Issues?

Extensions shouldn't be worse than additional ciphersuites.  The
problem about additional ciphersuites is that we'd have to duplicate
the number of allocated ciphersuites numbers to provide new PRFs for
otherwise well-known ciphersuites, and issue a number of boring RFCs
to get there.  And that's assuming that there's just a single
preffered new PRF, since otherwise we might end up triplicating,
quadruplicating, ..., the number of allocated ciphersuites (and we
only have a 16-bit namespace).

My preference would be for a new PRF that automatically is plugged
into all existing ciphersuites for the new protocol version.  I.e.,
protocol version negotiation and not ciphersuite negotiation
determines the PRF.  An extensions could be optional for those
who want to negotiate some PRF other than this default.

TLS mailing list