RE: [TLS] Updated TLS 1.2 I-D

<> Mon, 26 June 2006 14:20 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1Furx6-00069C-8x; Mon, 26 Jun 2006 10:20:36 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1Furx5-000697-2K for; Mon, 26 Jun 2006 10:20:35 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1Furx3-0003t7-JH for; Mon, 26 Jun 2006 10:20:35 -0400
Received: from ( []) by (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5QEKUlR014806; Mon, 26 Jun 2006 17:20:32 +0300
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 17:20:28 +0300
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 17:20:27 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] Updated TLS 1.2 I-D
Date: Mon, 26 Jun 2006 17:20:27 +0300
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [TLS] Updated TLS 1.2 I-D
Thread-Index: AcaYeCTojzNUKMoCQfaSyaM4ID4/dgAscReg
From: <>
To: <>, <>
X-OriginalArrivalTime: 26 Jun 2006 14:20:27.0083 (UTC) FILETIME=[ABC0F1B0:01C6992B]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
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: <>, <>

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.

I like this approach; it's simple, and I'm not convinced that anything
more complicated is needed. As was already pointed out some time ago,
even the current PRF looks quite secure: if someone really needs a
special PRF due to e.g. regulatory requirements, they'll probably 
need a new ciphersuite anyway.

However, I would take the approach even further towards simplicity:
use the current TLS PRF for all existing ciphersuites (instead of
tying it to the ciphersuite's MAC algorithm). Or in other words:
consider PRF as a property of the ciphersuite's key exchange 
algorithm (instead of the TLS protocol version or a property
that can be negotiated independent of key exchange algorithm).

(The document would then need a couple of new ciphersuites for 
the new PRF, but probably not very many combinations; after all,
if someone's worried that the current PRF is insecure, they're
not likely to use RC4 or IDEA. Maybe these new ciphersuites
could be the combined-mode ones.).

Best regards, 

TLS mailing list