Subject: [TLS] PRF in TLS 1.2

From: Wan-Teh Chang <[email-masked]>
Date: Mon, 18 Sep 2006 15:48:13 -0700

Hi,

Could someone please post a description of what was decided
about the PRF in TLS 1.2 in the Montreal WG meeting?

The only documents I can find on this topic are:

- Slide 7 of Eric's presentation
  (http://www3.ietf.org/proceedings/06jul/slides/tls-1.pdf)

- Eric's TLS WG Summary
   http://www1.ietf.org/mail-archive/web/tls/current/msg00698.html

But I can't tell from the WG summary what was decided and whether
the proposal in Slide 7 was accepted.

I'd also like to know what new PRFs have been proposed, and who
the proponents are.

The reason I'm interested in the PRF issue is that TLS 1.0
required an official interpretation from NIST to be acceptable
for use in FIPS mode.  (See the letter from William Burr of NIST
in IG 7.1, http://csrc.nist.gov/cryptval/140-1/FIPS1402IG.pdf .
Search for "Burr" or "TLS" in that document.)  I hope we can
eliminate such FIPS compliance issues in TLS 1.2.

But it's not clear to me whether not using MD5 in the PRF would be
sufficient for the PRF to be FIPS compliant, or we'd also need
to use one of the KDFs specified in NIST SP 800-56A, Section 5.8.
(http://csrc.nist.gov/publications/nistpubs/800-56A/sp800-56A_May-3-06.pdf)

Wan-Teh Chang

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 18 Sep 2006 15:57:49 -0700

> the proposal in Slide 7 was accepted.

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. 
2. All current cipher suites will use SHA-1 in TLS 1.2.
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.

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.

> I'd also like to know what new PRFs have been proposed, and who

The new PRFs that people seem interested in are:

1. The GOST PRF (draft-chudov-cryptopro-cptls-03.txt)
2. The FIPS 800-56A KDF.

-Ekr

---

From: Wan-Teh Chang <[email-masked]>
Date: Tue, 26 Sep 2006 13:49:02 -0700

>    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"?

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

>    "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?

>         the record HMAC unless otherwise specified in the cipher

Thanks.  When do you plan to publish a new version of the I-D?

Wan-Teh

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Sep 2006 14:48:37 -0700

> "If it ain't broke, don't fix it"?

I would phrase it as "make the most minimal change possible"

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

> of their concatenation label + seed?

No, I don't think so

> 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

---

From: Wan-Teh Chang <[email-masked]>
Date: Wed, 27 Sep 2006 07:30:39 -0700

> 1. The GOST PRF (draft-chudov-cryptopro-cptls-03.txt)

The GOST PRF, PRF_GOSTR3411, is defined in RFC 4357 as

   PRF_GOSTR3411(secret,label,seed) = P_GOSTR3411 (secret,label|seed)

   where '|' stands for concatenation.

It is actually an instance of the default TLS 1.2 PRF,
with <hash> = the GOST R 34.11-94 hash function.  This
isn't a coincidence, is it?

> 2. The FIPS 800-56A KDF.

Appendix A, Item 8 of NIST SP 800-56A says this KDF
comes from ANS X9.42 and X9.63, but NIST made some minor
(and perhaps subtle) changes (e.g., the order of the counter
and secret is reversed).  I don't know if this KDF is
used in any other standard or protocol.

Perhaps we should ask NIST if P_SHA-1, P_SHA-256, and
P_SHA-384 are allowed in TLS in FIPS mode.

Wan-Teh