[TLS] Extended nonces

Eric Rescorla <ekr@networkresonance.com> Mon, 21 August 2006 20:08 UTC

Received: from [] (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 [] (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 ([] 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 ([]) 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 []) 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
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


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

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 + 

Do people see a problem with this?



TLS mailing list