Re: [TLS] Review comments on draft-rescorla-tls-opaque-prf-input-00.txt

<> Thu, 18 January 2007 04:51 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1H7PEu-00057H-7V; Wed, 17 Jan 2007 23:51:04 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1H7PEs-00057A-Ul for; Wed, 17 Jan 2007 23:51:02 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1H7PEr-0007hk-Kq for; Wed, 17 Jan 2007 23:51:02 -0500
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.2668); Wed, 17 Jan 2007 20:51:01 -0800
Received: from mail pickup service by with Microsoft SMTPSVC; Wed, 17 Jan 2007 20:51:00 -0800
Message-ID: <BAY126-DAV192028B2EA5EB9D23929D892AA0@phx.gbl>
Received: from by BAY126-DAV19.phx.gbl with DAV; Thu, 18 Jan 2007 04:50:56 +0000
X-Originating-IP: []
X-Originating-Email: []
To: Wan-Teh Chang <>, tls mailing list <>
References: <>
Subject: Re: [TLS] Review comments on draft-rescorla-tls-opaque-prf-input-00.txt
Date: Wed, 17 Jan 2007 20:50:54 -0800
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="response"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223
X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223
X-OriginalArrivalTime: 18 Jan 2007 04:51:00.0915 (UTC) FILETIME=[4039F030:01C73ABC]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
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: <>, <>

Extending the length of the contributed Nonce information in 
the PRF is nicely disclosed, in section 3.2.

What is interesting now is the session resumption 
disclosure. This may explain why Eric is so adamant that he 
can FORCE a new handshake, so he can refresh the extensions 
values for a new TLS Connection?

But, as disclosed, its more confusing than before. Now the 
opaque PRF can only be used in pre-master-secret to master 
secret generation. In the other document and earlier in the 
paper, it seemed opaque PRF was being given a rationale for 
use in final KDF;'s generation of keying material.

Between protocol analysis, hacking some extensions to extend 
the nonce, PRF parameterization, the way it handles session 
resumption and kind of reverses its rationale... this doesn't 
look a polished and finished piece of work. is "feels" like 
work in progress, attempting to apply external policy to 
standards making.

Again, I cannot find any reason not to do this, or be open 
about it!


3.2.  PRF Modifications

   When the opaque PRF input feature is in use, the opaque 
PRF input
   values MUST be mixed into the PRF along with the client 
and server
   random values during the PMS->MS conversion.  Thus, the 
PRF becomes:

          master_secret = PRF(pre_master_secret, "master 
                              ClientHello.random +
                              ServerHello.random +

   Because new extensions may not be introduced in resumed 
   mixing in the opaque PRF inputs during the MS->keying 
   conversion would simply involve mixing in the same 
material twice.
   Therefore, the opaque PRF inputs are only used when the 
PMS is
   converted into the MS.


TLS mailing list