[TLS] Updated TLS 1.2 I-D

Eric Rescorla <ekr@networkresonance.com> Sun, 25 June 2006 16:54 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuXsZ-0000Fa-QU; Sun, 25 Jun 2006 12:54:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuXsY-0000FU-84 for tls@ietf.org; Sun, 25 Jun 2006 12:54:34 -0400
Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuXsU-00036f-Tx for tls@ietf.org; Sun, 25 Jun 2006 12:54:34 -0400
Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id E4704222425 for <tls@ietf.org>; Sun, 25 Jun 2006 10:02:41 -0700 (PDT)
To: tls@ietf.org
X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19)
Date: Sun, 25 Jun 2006 09:54:30 -0700
From: Eric Rescorla <ekr@networkresonance.com>
Message-Id: <20060625170241.E4704222425@laser.networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc:
Subject: [TLS] Updated TLS 1.2 I-D
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

I've submitted an update TLS 1.2 I-D an in the meantime
you can find it at:

http://scm.sipfoundry.org/rep/ietf-drafts/ekr/tls/tls.txt

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@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls