[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] PRF in TLS 1.2
Wan-Teh Chang <wtchang@xxxxxxxxxx> writes:
> Eric Rescorla wrote:
>>
>> Here's a summary of what was decided.
>> 1. The default PRF is the TLS 1.1 PRF with a single hash algorithm
>> and the entire key used as input to P_hash.
>
> What's the rationale for defining the default TLS 1.2 PRF
> to be similar to the TLS 1.1 PRF?
>
> To allow developers to reuse as much of their TLS 1.0/1.1
> implementation as possible?
>
> "If it ain't broke, don't fix it"?
I would phrase it as "make the most minimal change possible"
>> 2. All current cipher suites will use SHA-1 in TLS 1.2.
>
> Will using SHA-1 only result in a weaker PRF than the TLS 1.1 PRF,
> which uses both MD5 and SHA-1?
This would be a good question to direct at Dan Simon or Hugo Krawczyk.
My intuition is that because the secret is split between the two
hashes in the current PRF, this PRF would be arguably stronger
than the current PRF if MD5 is badly compromised. In any case,
this is a general question of whether we want two hashes
rather than a detailed one abt construction.
>> 3. New cipher suites will by default use the TLS 1.1 PRF with whatever
>> hash they're using for HMAC.
>> 4. New cipher suites can define a new PRF but it must use the same
>> "API" as the TLS 1.1 PRF.
>
> Is it required that the PRF use label and seed only in the form
> of their concatenation label + seed?
No, I don't think so
>> This is roughly what's in the current I-D, except that I deleted
>> a crucial paragraph through sloppy editing. It should read
>> approximately:
>> The PRF is derived from P_hash as:
>> PRF(secret, label, seed) = P_<hash>(secret, label + seed)
>> Where <hash> is dependent on the cipher suite. For the
>> cipher suites defined in this document it SHALL be SHA-1.
>> For future cipher suites it SHALL be the hash used in
>> the record HMAC unless otherwise specified in the cipher
>> suite description.
>
> Thanks. When do you plan to publish a new version of the I-D?
Definitely before San Diego. Other than that, as soon as I get
some time...
-Ekr
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls