Re: [TLS] Updated TLS 1.2 I-D

Eric Rescorla <ekr@networkresonance.com> Mon, 26 June 2006 13:42 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurMh-0008B0-Tk; Mon, 26 Jun 2006 09:42:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurMg-00086P-MA for tls@ietf.org; Mon, 26 Jun 2006 09:42:58 -0400
Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FurMe-0000sT-Az for tls@ietf.org; Mon, 26 Jun 2006 09:42:58 -0400
Received: by raman.networkresonance.com (Postfix, from userid 1001) id 82D1C1E8C1F; Mon, 26 Jun 2006 06:42:55 -0700 (PDT)
To: Bodo Moeller <bmoeller@acm.org>
Subject: Re: [TLS] Updated TLS 1.2 I-D
References: <20060625170241.E4704222425@laser.networkresonance.com> <20060626095522.GA28012@iota.site>
From: Eric Rescorla <ekr@networkresonance.com>
Date: Mon, 26 Jun 2006 06:42:55 -0700
In-Reply-To: <20060626095522.GA28012@iota.site> (Bodo Moeller's message of "Mon, 26 Jun 2006 11:55:22 +0200")
Message-ID: <86mzc0av8g.fsf@raman.networkresonance.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR <ekr@networkresonance.com>
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

Bodo Moeller <bmoeller@acm.org>; writes:

> On Sun, Jun 25, 2006 at 09:54:30AM -0700, Eric Rescorla wrote:
>
>> 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?
>
> Extensions shouldn't be worse than additional ciphersuites.  The
> problem about additional ciphersuites is that we'd have to duplicate
> the number of allocated ciphersuites numbers to provide new PRFs for
> otherwise well-known ciphersuites, and issue a number of boring RFCs
> to get there.  And that's assuming that there's just a single
> preffered new PRF, since otherwise we might end up triplicating,
> quadruplicating, ..., the number of allocated ciphersuites (and we
> only have a 16-bit namespace).
>
> My preference would be for a new PRF that automatically is plugged
> into all existing ciphersuites for the new protocol version.

Yes, that's my plan.

>  I.e.,
> protocol version negotiation and not ciphersuite negotiation
> determines the PRF.  An extensions could be optional for those
> who want to negotiate some PRF other than this default.

But the flip side of using extensions that way is that we
move more and more of the protocol into extensions. I wonder
if it's becoming time to consider breaking up the ciphersuite
into orthogonal parameters.

-Ekr


_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls