Re: [TLS] Updated TLS 1.2 I-D

On Mon, Jun 26, 2006 at 05:20:27PM +0300, Pasi.Eronen@nokia.com wrote:

>> 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.

> I like this approach; it's simple, and I'm not convinced that anything
> more complicated is needed. As was already pointed out some time ago,
> even the current PRF looks quite secure: if someone really needs a
> special PRF due to e.g. regulatory requirements, they'll probably 
> need a new ciphersuite anyway.
> 
> However, I would take the approach even further towards simplicity:
> use the current TLS PRF for all existing ciphersuites (instead of
> tying it to the ciphersuite's MAC algorithm). Or in other words:
> consider PRF as a property of the ciphersuite's key exchange 
> algorithm (instead of the TLS protocol version or a property
> that can be negotiated independent of key exchange algorithm).

If you take into account SSL 3.0, then the PRF already *is* a property
of the TLS protocol version, though.  And the current TLS PRF, with
its input-splitting dual-hash construction, is somewhat bizarre, so a
reasonable simple new PRF, based on a wider hash, wouldn't be bad --
providing the advantage that those who want to avoid the current
TLS PRF in their favorite ciphersuites won't have to define additional
ciphersuites just to get another PRF, as long as they are reasonably
happy with the new default if we decide on one.

> (The document would then need a couple of new ciphersuites for 
> the new PRF, but probably not very many combinations; after all,
> if someone's worried that the current PRF is insecure, they're
> not likely to use RC4 or IDEA. Maybe these new ciphersuites
> could be the combined-mode ones.).

This wouldn't be too many new ciphersuites if you consider just those
that are in the main TLS specification.  But then there are other
ciphersuites in other RFCs, so we have to expect to see updates of
these for the new PRF too if the PRF is not tied to the protocol
version.  Unless a single RFC does this for the ciphersuites from
different existing RFCs (which do not even share a common status),
this wouldn't really provide simplicity -- we'd have to expect a
multitude of RFCs defining new ciphersuites, possibly most of them
using the same PRF, possibly with some hand-tailored PRFs that are
slightly optimized for the specific ciphersuites.  Even if a single
RFC does this for ciphersuites originally coming from different RFCs,
the complete ciphersuite table would grow in length and entropy.

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