Subject: [TLS] The TLS PRF

From: Eric Rescorla <[email-masked]>
Date: Sat, 18 Feb 2006 13:40:00 -0800

People will recall that the current TLS PRF uses HMAC_MD5 and HMAC_SHA1
in tandem. In [BR05], Steve and I recommended that this be amended to
solely use HMAC_X where X is the hash algorithm defined as the hash
function negotiated for the cipher suite. This has three major
difficulties:

1. The TLS PRF is different from the one specified in NIST SP 800-56
   S 5.8.1. The TLS PRF is approved only for parameter sets 
   FA and EA, which themselves are only approved up to 2010.

2. The TLS PRF depends on a hash function and so can't be used
   with MAC algorithms that are not hash-based. So, for instance,
   you couldn't use CCM or GCM mode. (Note that this is an issue
   with the 800-56 KDF as well).

3. You can't use it with algorithm suites that define their own
   KDF, such as GOST and potentially Suite B.

In some sense these are separable problems.  I think clearly we need to
specify a standard TLS KDF (and note that we also use the PRF in
Finished), so that at least that KDF can be usable by all of the
ciphersuites we currently have.  And the recommendation to use
the ciphersuite-negotiated hash function still seems sound.
So, that leaves us with three questions:

1. Should the Hash-based PRF be based on the current PRF or NIST
   800-56? 

2. Should we define a standard non-Hash-based PRF? Where would
   we get it from? If not, what PRF should be used with GCM/CCM/etc.?

3. Should we allow the negotiation of ciphersuite-specific PRFs?

Can we get some discussion this issue please?

-Ekr

   

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

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 20 Feb 2006 00:14:54 +1300

>Can we get some discussion this issue please?

There's a great quote from "The Inmates Are Running the Asylum": Geeks will
repeatedly fix what isn't broken until it is.

Why is the TLS PRF broken?  What's the pressing need for (say) a PRF that we
can build with GCM?  Is it because it's trendy?  Do we need more features for
a marketing checklist?

The current PRF has been around for 10 years, and in that time the only real
argument against it has been that it doesn't meet someone's taste in fashion
(e.g. the GOST case).  It's not broken, and doesn't show any sign of ever
being broken, let's leave the poor thing alone.

Peter.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 19 Feb 2006 07:20:21 -0800

> being broken, let's leave the poor thing alone.

Hmmm... I thought I explained myself clearly the first time, but
apparently not.

In TLS 1.2 we're attempting to replace the hardwired MD5/SHA-1
PRF with one that is not hardwired. The natural proposal is to
use the hash function that corresponds to the HMAC used for
message integrity. But if you're not using HMAC for message
integrity (say because you're using GCM) then there's no
obvious choice.

-Ekr

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 20 Feb 2006 16:14:14 +1300

Eric Rescorla <[email-masked]> writes:

>Hmmm... I thought I explained myself clearly the first time, but apparently
>not.

You did, but... well, let me paraphrase your question as I understood it :-),
and the same for my response.

Question: Here are a bunch of hypothetical scenarios under which someone, if
  they really wanted to be awkward, could claim the current PRF offends their
  fashion sense.  Should we accomodate them, or tell them to get a life?

Response: The current PRF has stood the test of time, implementing other PRFs
  is a major implementation and interop headache (especially if we were to get
  a combinatorial explosion of PRFs that all need interop testing with each
  other), and there's no technical reason to introduce more of them.
  Specifically, no-one would be prevented from being able to create a secure
  TLS implementation using the current PRF.  Tell 'em to get a life - let's
  solve real problems like the (critical) secure phishing problem before we
  start debating which colour to re-paint the (completely noncritical) PRF.

Peter.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 19 Feb 2006 21:10:34 -0800

>   fashion sense.  Should we accomodate them, or tell them to get a life?

Yeah, well, that's the problem here. The scenarios aren't hypothetical,
or I wouldn't have raised them.

Let's just focus on one for the moment.

1. We're planning to replace the HMAC/MD5 PRF with one that's based
   on the hash used in the cipher suite HMAC.
2. People have requested the addition of non-HMAC-based cipher suites.

These two together create a conflict that needs to be resolved somehow.

Now, your response could be (at least) one of:
1. Don't replace HMAC/MD5 combo with something else.
2. Don't add non-HMAC-based cipher suites.
3. Somehow specify a way to use the TLS PRF with case (2), e.g.
   by specifying a PRF hash in the cipher suite.
4. Specify a new PRF.

Now, I believe there's rough consensus to do task (1), so that
precludes response (1). Task (2) is in our charter, so that
precludes response (2)--which leaves us with at least some
task to do to make this work. 

You could of course argue about either of these points and attempt to
establish an alternative consensus, but just telling people to get a
life doesn't really get the job done. As for the issue of phishing,
I agree that that's a problem, but it's not the TLS WG's problem,
so complaining that we're working on something else makes about
as much sense as complaining that we're not working on a cure for 
HIV.

-Ekr

---

From: Dmitry Belyavsky <[email-masked]>
Date: Mon, 20 Feb 2006 12:17:10 +0300 (MSK)

Greetings!

> being broken, let's leave the poor thing alone.

In Russia we have to implement GOST-based PRF because of our goverment
restrictions. So leaving current PRF hard-coded will leave some our
problems with us...

-- 
SY, Dmitry Belyavsky (ICQ UIN 11116575)

---

From: "Tim Dierks" <[email-masked]>
Date: Mon, 20 Feb 2006 11:53:50 -0500

The design goal of the original SSL3 PRF was to be more secure than
any single ciphersuite's hashing algorithm. This was necessary because
otherwise, any vulnerable ciphersuite supported by both sides allows a
MITM to downgrade the handshake to the vulnerable ciphersuite. As
things are at the moment, even if you had a crack on MD5, you couldn't
leverage it to keep two parties from negotiating AES/SHA1, even if
they both also supported RC4/MD5. If we reduce the PRF to using the
hash from the negotiated cipher suite, this will no longer be true.

What's the rationale for replacing the current PRF with a ciphersuite-based one?

 - Tim

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 21 Feb 2006 22:43:25 +1300

Eric Rescorla <[email-masked]> writes:

>The scenarios aren't hypothetical, or I wouldn't have raised them.

I guess we'll just have to agree to disagree on this - it looks to me like a
bunch of artificial justifications to support messing with something that's
just fine as it is, but I guess you're seeing it differently.

>establish an alternative consensus, but just telling people to get a life
>doesn't really get the job done.

My comment was to leave things as they are.  The "get a life" (and emoticon)
were tongue-in-cheek.

>As for the issue of phishing, I agree that that's a problem, but it's not the
>TLS WG's problem, so complaining that we're working on something else makes
>about as much sense as complaining that we're not working on a cure for HIV.

Not phishing, secure phishing, i.e. use of TLS server authentication as part
of the phishing process.  I think building systems that make phishing easier
probably isn't a good idea, and that it'd be more productive to look at ways
of fixing this problem than to fiddle with random bits of the protocol that
work just fine as they are.  Again though I guess our opinions differ...

Peter.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Feb 2006 07:13:30 -0800

> just fine as it is, but I guess you're seeing it differently.

Obviously. But all you've done is assert it's just fine 
as it is, without actually explaining why these scenarios aren't
relevant, which really isn't that helpful. If you'd actually
bother to respond in detail, we might not have to agree to
disagree.

> work just fine as they are.  Again though I guess our opinions differ...

Do you have a proposal for a way to fix the problem that the TLS WG
should be working on? If not, I really don't see your point here.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Feb 2006 13:44:42 -0800

> What's the rationale for replacing the current PRF with a

Well, for any of this to make sense you have to assume that 
there's some concern that there will be a useful preimage 
attack on one of the hash functions that might potentially
be in the PRF. At the moment all we know is that we're not
meeting the design goals on SHA-1 and MD5 which is a long
way from a preimage.

That said, consider the following scenario:

1. There's a useful preimage attack on SHA-1 and MD5. 
2. People convert to SHA-256 in their ciphersuite HMAC and
   turn off all non SHA-256 ciphersuites.
3. There are two ciphers of different strengths that both
   use SHA-256.

In this case, if we don't change the PRF you could downgrade
between those two ciphers. OTOH, if we do change the PRF, 
you could. I think it's realistic to argue that any compromise
in HMAC bad enough to implicate the PRF would also require people
to turn off that algorithm in their ciphersuites.

So, the motivation here is not to get stuck in that situation.
I agree that it's unlikely, but I see it as future-proofing.
Note, btw, that this exact issue was on my slides in Vancouver.

At a higher level, there are 5 major places where TLS uses
hashes:

- Cert signatures
- Record MACs

- PRF
- Digitally-signed operator
- Finished (also PRF)

Now, the record MACs negotiate just fine. And the cert signatures can
be done with an extension. So, that leaves the remaining three
choices, which all use MD5 and SHA-1 in tandem (with the exception of
with DSA). Do people feel we can leave those as-is? 

-Ekr

---

From: "Tim Dierks" <[email-masked]>
Date: Tue, 21 Feb 2006 18:21:59 -0500

> 3. There are two ciphers of different strengths that both

For #1 to defeat any of the mechanisms, you need a single preimage
attack that works with both md5 and sha1, which, furthermore, can be
executed within the protocol constraints of TLS (although the latter
probably isn't too high of a bar).

I think #2 is unlikely to ever happen in practice. SSL 2 is still on
by default everywhere I'm familiar with.

On the other hand, if we make this switch, a preimage attack on any
supported hash which hasn't been disabled is sufficient to subvert the
handshake mechanism, and thus force you to use the subverted hash.

I'd prefer for us to replace the PRF with the best available hashing
system we've got rather than use the negotiated hash. And, in the
model of SSL3/TLS1, I'd use two disparate systems to try to avoid
single points of failure. For example, we could replace SHA-1 with
SHA-256 in the PRF. Furthermore, we could replace MD5 with another
hash which has a very different structure from SHA-256 (off the cuff,
and without any real knowledge, I'd consider using a hashing
construction built from AES).

 - Tim

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 21 Feb 2006 18:32:52 -0500

In message <[email-masked]>, "Tim 

>by default everywhere I'm familiar with.

IE7 beta turns off SSL2 by default.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 22 Feb 2006 15:30:39 +1300

Eric Rescorla <[email-masked]> writes:
>Do you have a proposal for a way to fix the problem that the TLS WG should be
>working on? If not, I really don't see your point here.

I was suggesting that this might be a more productive (or more importantly,
far more pressing) area to focus our attention on.  Like (I would guess) most
people I've got various ideas on how this might be addressed, the main one
being to strongly promote a TLS-PSK -like mechanism (with mutual challenge-
response authentication built into the handshake) in place of certs (where you
connect to anything with a cert and then send the username and password to the
server completely unprotected).  What I was doing was trying to foster
discussion, not present some fait-accompli pre-packaged solution.

Peter.

---

From: Russ Housley <[email-masked]>
Date: Tue, 21 Feb 2006 12:13:32 -0500

Tim:

Thanks for reminding us about the original design goal.  I think this 
is still an important consideration, but it is no longer the case I believe.

There is also a political consideration.  Presently, an exception is 
needed to use the TLS PRF in the US Government since it make use of a 
non-FIPS algorithm.  Similarly, the TLS PRF is not acceptable to the 
Russian Government since it makes use of a non-GOST document.

Russ