Subject: [TLS] Straw poll about default PRF

From: "Pasi Eronen" <[email-masked]>
Date: Thu, 19 Oct 2006 16:09:01 +0300

Let's try to close the default PRF issue before the San Diego 
meeting.

To summarize the issue: to meet its chartered goal of removing
dependencies to MD5 and SHA-1, TLS WG will most likely specify a 
PRF that is not based on MD5/SHA-1 (the exact details will be 
determined separately). TLS 1.2 will also most likely allow new 
ciphersuites to specify a ciphersuite-specific PRF (e.g. the 
GOST ciphersuites).

The remaining question is exactly how the PRF negotiation will 
work for those ciphersuites that don't specify anything, especially 
all the currently defined ciphersuites.

The two main alternatives seem to be as follows:

   1) Default PRF is tied to the TLS version number: in other words, 
   ciphersuites that don't specify anything else (including all 
   currently defined ciphersuites) will use the new TLS 1.2 PRF 
   (details of which are TBD) when TLS 1.2 is negotiated.

   2) The new PRF will be used only for new ciphersuites that
   explicitly say so; all currently defined ciphersuites continue to
   use the current (TLS 1.0/1.1) PRF even when TLS 1.2 is negotiated.

Clearly neither alternative is horribly broken or unworkable, so this
is mainly a question of "which seems nicer". Some arguments that
have been made are as follows:

- Option 1 is not necessary, since there are no practical attacks
  against the current PRF (yet)
- Option 1 can cause implementation and/or interop problems
- On the other hand, changing PRF in SSLv3->TLS1.0 did not cause 
  big implementation and/or interop problems (there are interop 
  problems, but not because of the PRF).
- With option 1, all ciphersuites benefit without having to get
  new numbers (and there are lots of RFCs that would have to
  be updated).
- In order to have secure negotiation, all the PRFs that both
  sides support have to be secure against a specific kind of
  active attack (true, but would this suggest option 1 or 2,
  or neither?).
- TLS versions older than 1.2 have to be enabled for long time
  (true, but would this suggest option 1 or 2, or neither?).

Please state your opinion on the WG list within a week. When 
judging the WG consensus, I will also take into account the 
sense of the room at Montreal, where support for option 1 was 
practically unanimous.

Best regards,
Pasi

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 19 Oct 2006 09:31:37 -0400

I prefer Option 1.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 19 Oct 2006 15:37:58 +0200

>    use the current (TLS 1.0/1.1) PRF even when TLS 1.2 is negotiated.
...
> Please state your opinion on the WG list within a week.

I have a (mild) preference for alternative 2 for these reasons:

* I prefer if all negotiations that influence which cryptographic
  algorithms are used is negotiated through the cipher suites.

* I prefer to de-couple PRF negotiation from TLS version level
  negotiation.

  Consider this: What if the new TLS 1.2 default PRF is broken, but
  the current TLS PRF is not broken?

  What should implements do?  Stop using TLS 1.2 and negotiate TLS
  1.1?  That would be quite unfortunate, especially if TLS 1.2 fixes
  other security problems or add important new features that
  implementations need.

* The TLS version number negotiation appears to be fragile.
  (Although, if TLS 1.2 fixed this problem with stricter text, and
  implementations followed it, this argument would go away.)

To me, there is only one disadvantage with alternative 2:

* We need to specify new cipher suites that use the new PRF.  That's
  some work, but seems do-able.

I could change my mind if some good arguments against 2 are presented.

/Simon

---

From: Sami Lehtinen <[email-masked]>
Date: Thu, 19 Oct 2006 16:37:10 +0300

Option 1, please.

Pasi Eronen wrote:
[SNIP]
>    (details of which are TBD) when TLS 1.2 is negotiated.
[SNIP]

-- 
[email-masked]

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 19 Oct 2006 15:41:01 +0200

On Thu, Oct 19, 2006 at 04:09:01PM +0300, Pasi Eronen wrote:

[...]
>    use the current (TLS 1.0/1.1) PRF even when TLS 1.2 is negotiated.
[...]
> sense of the room at Montreal, where support for option 1 was 

Really?  According to Eric (<[email-masked]>,
18 Sep 2006), what was decided at Montreal was

< 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 variant looks worse to me than #1 above in that it would limit
existing ciphersuites to strictly 160-bit security for encryption (and
would limit the encryption security for new ciphersuites using these
defaults to whatever is deemed sufficient for authentication), and
would lead to a complicated situation where there are multiple PRFs
and where essentially similar ciphersuites might be using different
PRFs.

Option #1 above makes sense, provided that the new PRF is an actual
256-bit PRF or better.  But if no suitable candidate is agreed upon,
then we should rather stay with #2 until something apropriate comes
up.  Sorry for not sticking with one of the two options as you
outlined them ...

Bodo

---

From: badra <[email-masked]>
Date: Thu, 19 Oct 2006 15:42:49 +0200

I think it is better to don't ties the PRF only to the TLS version 
number. Let us tie it to the identifier of the cipher_suite too.

Best regards,
Badra

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Oct 2006 15:46:15 +0200 (MET DST)

>    (details of which are TBD) when TLS 1.2 is negotiated.

I would prefer (1) over (2) *IF*, and only if the new PRF will _NOT_
need all of the handshake messages to be stored for the entire handshake.

-Martin

---

From: Russ Housley <[email-masked]>
Date: Thu, 19 Oct 2006 10:26:45 -0400

Simon:

If the TLS 1.2 PRF gets broken, can't a server demand the use of a 
ciphersuite that specifies its own yet-to-be-broken PRFs?

Russ

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 19 Oct 2006 17:23:34 +0200

> ciphersuite that specifies its own yet-to-be-broken PRFs?

Yes, true, pending that such ciphersuites are specified and deployed.

It could also fall back to TLS 1.1 and use the old PRF.  If TLS >= 1.2
fixes other security problems, compared to TLS 1.1, there would be a
tradeoff: either run with the risks with a broken TLS 1.2 PRF or the
risks of the things broken in TLS 1.1 but fixed in TLS >= 1.2.

I consider it unlikely that the TLS 1.2 PRF will be broken faster than
the TLS 1.0 PRF -- although stranger things have happened... -- hence my
preference is only a mild one.  It is primarily based on the first
bullet below.

/Simon

---

From: Ari Medvinsky <[email-masked]>
Date: Thu, 19 Oct 2006 17:01:29 -0700

I prefer method 1, I think that it's a cleaner approach then making prf
explicit in all new ciphersuites 

-----Original Message-----
From: Simon Josefsson [mailto:[email-masked]] 
Sent: Thursday, October 19, 2006 8:24 AM
To: Russ Housley
Cc: Pasi Eronen; tls mailing list
Subject: Re: [TLS] Re: Straw poll about default PRF

/Simon

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 20 Oct 2006 01:22:08 +0100

I vote for Option 1.

Stefan Santesson
Senior Program Manager
Windows Security, Standards
> From: Pasi Eronen [mailto:[email-masked]]
> Sent: den 19 oktober 2006 06:09
> To: tls mailing list
> Subject: [TLS] Straw poll about default PRF
> 
>

---

From: Wan-Teh Chang <[email-masked]>
Date: Thu, 19 Oct 2006 18:21:36 -0700

>    use the current (TLS 1.0/1.1) PRF even when TLS 1.2 is negotiated.

I vote for option 1.

Wan-Teh Chang

---

From: "tom.petch" <[email-masked]>
Date: Fri, 20 Oct 2006 09:56:28 +0200

Option 2

(Option 1 may be suitable for the present situation but may become a liability
at the next version change.  Option 2 gives us the better long term control).

Tom Petch

---

From: Rob Dugal <[email-masked]>
Date: Fri, 20 Oct 2006 06:45:27 -0400

I prefer option 1.

-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: [email-masked]
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com