Re: [TLS] Updated TLS 1.2 I-D

"Kyle Hamilton" <> Mon, 26 June 2006 05:21 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1FujXI-0000Mg-PB; Mon, 26 Jun 2006 01:21:24 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1FujXG-0000Ma-Uv for; Mon, 26 Jun 2006 01:21:22 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1FujXE-0006xQ-JP for; Mon, 26 Jun 2006 01:21:22 -0400
Received: by with SMTP id d4so815066nfe for <>; Sun, 25 Jun 2006 22:21:19 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta;; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bXW1u62yowKrFm7bBiGHkIziWQf8fqnSvK7uZ/Wiwa3ptqfd9Gz47vbbGmoQ6D7Qh6dV6a9T7JxlQdq9Ew2r7g9cDxk+qeGE73NXFN0NR/Nd1dVbB9nbjjb3eMEH9wDVKt53JzxjzqW90+cUBMWiAesbKtHGuX9xEt2aq+54LN4=
Received: by with SMTP id p3mr4533791nfh; Sun, 25 Jun 2006 22:21:19 -0700 (PDT)
Received: by with HTTP; Sun, 25 Jun 2006 22:21:19 -0700 (PDT)
Message-ID: <>
Date: Sun, 25 Jun 2006 22:21:19 -0700
From: "Kyle Hamilton" <>
To: "Eric Rescorla" <>
Subject: Re: [TLS] Updated TLS 1.2 I-D
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
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: <>, <>

I'm curious, why does having it as an extension make you
uncomfortable?  The way I see it, the PRF will need to be the same on
both sides in order for the handshake to complete, even if it's
negotiated via extension.  If it's not, then the server (and/or the
client) will get what should be the handshake_complete packet, and be
unable to decrypt it properly.  When they do, they'll run the hash
over it, see that it doesn't match, and throw a decrypt_error or
decode_error fatal alert.

Though this would be a good way for Mallory to mount a DOS attack
against the server and/or client (insert an extension to select the
PRF), that possibility is already incumbent in the handshake protocol
regardless (and has been there since at least TLS 1.0, allowing extra
data (which later became 'extensions') after the end of the

An extension of this type (and let's face it, 'extensions' were
introduced so that the protocol could be extended beyond its original
capability), even though it is recommended not to be put in place,
appears to be cryptographically sound.

I've got a couple of comments and questions on the draft (and
protocol) itself; I'll put them in a separate email.

-Kyle H

On 6/25/06, Eric Rescorla <> wrote:
> I've submitted an update TLS 1.2 I-D an in the meantime
> you can find it at:
> 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?
> -Ekr
> _______________________________________________
> TLS mailing list

TLS mailing list