[TLS] Extended nonces
Eric Rescorla <ekr@networkresonance.com> Mon, 21 August 2006 20:08 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFG4s-00085o-Qe; Mon, 21 Aug 2006 16:08:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFG4r-00085S-6u for tls@ietf.org; Mon, 21 Aug 2006 16:08:53 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFEC1-0001Jv-Vz for tls@ietf.org; Mon, 21 Aug 2006 14:08:10 -0400
Received: from laser.networkresonance.com ([198.144.196.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFDiQ-0006e2-DF for tls@ietf.org; Mon, 21 Aug 2006 13:37:36 -0400
Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 2D68A222425 for <tls@ietf.org>; Mon, 21 Aug 2006 10:45:31 -0700 (PDT)
To: tls@ietf.org
X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19)
Date: Mon, 21 Aug 2006 10:37:33 -0700
From: Eric Rescorla <ekr@networkresonance.com>
Message-Id: <20060821174531.2D68A222425@laser.networkresonance.com>
X-Spam-Score: -2.4 (--)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc:
Subject: [TLS] Extended nonces
X-BeenThere: tls@lists.ietf.org
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." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org
Folks, Some folks from the USG have recently raised a requirement with me that I thought deserved some consideration from the WG. The issue is that they would like to have the client and server provide some opaque (to TLS) but structured data which is then fed into the PRF so that the traffic keys depend on it. Because the data is longer than 32 bytes it can't be packed into the Random structure and because it's structured and needs to be parsed on the other end, it can't be hashed and then placed in the Random. My thought was that they should define a new extension, something like: struct { opaque material<255>; } PublicKeyingMaterial; By offering this extension the client would be saying: 1. I want to do this extension, here's my data. 2. Please provide your own data. If the server doesn't respond with the extension it's not used. We would then mix these into the PRF as follows: master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + Client.PublicKeyingMaterial + ServerHello.random + Server.PublicKeyingMaterial)[0..47]; Do people see a problem with this? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- [TLS] Extended nonces Eric Rescorla