Re: [TLS] Updated TLS 1.2 I-D

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