Subject: RE: [TLS] PRF proposal

From: "Blumenthal, Uri" <[email-masked]>
Date: Mon, 20 Nov 2006 09:51:57 -0500

It is a good proposal. I'm for it.

I've one question. People are working on a better hash and PRF now.
Practically speaking, there is no way to retrofit such a new hash/etc to
the older already-existing/deployed cipher-suites, correct?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, November 20, 2006 9:13 AM
To: [email-masked]
Subject: [TLS] PRF proposal

Hi,

We had a rather complicated discussion about the PRF issue in San
Diego, and in the end we did not take a humm because it was not quite
clear what the alternatives we would be choosing from really are (or
whether the proposed alternatives really were different at all).

Here's a strawman proposal that tries to capture the comments
made in San Diego:

o  Future documents that define ciphersuites must explicitly say 
   either that (1) "the ciphersuites defined in this document use 
   the default PRF for the negotiated TLS version", or (2) "the 
   ciphersuites defined in this document use the following PRF: 
   (details of the PRF)".

   Especially documents that use something better than SHA-256 for
   integrity protection should use the latter choice (presumably
   defining a PRF based on the algorithm it considered "better
   than SHA-256"). Other documents might prefer choice 1 since 
   that  would avoid updating them if someday we define TLS 1.3 
   or something.

o  In 4346bis, define the "default PRF for TLS 1.2" as P_SHA256.

o  In 4346bis, specify that all ciphersuites defined in old 
   documents predating the above-mentioned requirement use 
   choice 1 ("the default PRF for the negotiated TLS version").
   (Already implied by the earlier decision.)

o  Specify that all ciphersuites defined in 4346bis use choice 1.

Would this be satisfactory to everyone? Any other comments?

Best regards,
Pasi

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

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

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 20 Nov 2006 16:50:43 +0100

> the older already-existing/deployed cipher-suites, correct?

Assume that a great new PRF comes up.

If everybody wants to use that PRF, then the existing ciphersuites
would be retrofitted to use the new PRF by making it the default
for, say, TLS 1.3.

If only some folks want to use the new PRF, then it could be used with
existing ciphersuites by defining a TLS extension allowing PRF
negotiation.  (There's no need to define such an extension before
there is a PRF worth the extra protocol complexity.)

If you want to change more than just the PRF (e.g. if you want to
change the hash function used within HMAC, or use some non-HMAC
variant of a current HMAC ciphersuite), you probably should define a
new ciphersuite.  But the hash functions used within HMAC aren't that
important anyway (attacks against authentication must be executed in
real time to achieve anything), so generally this should't be much of
a problem.  The PRF used for key derivation is much more important
than that, so a need for PRF negotiation via a TLS extension looks
much more likely.  (If there *was* a great new MAC that everyone
wanted to use, then theoretically we could define a TLS extension for
negotiating its use in place of HMAC with SHA-1 in existing
ciphersuites.  This just doesn't appear too likely.)

>    ciphersuites defined in this document use the following PRF: 
[...]
> Would this be satisfactory to everyone? Any other comments?

Generally this looks very reasonable, I'd just change the wording:
Currently, it only foresees having the default PRF tied to the TLS
version; I'd also mention a provision for negotiating the PRF through
a TLS extension.  So in case (1), documents would say something along
the lines of

     "The ciphersuites defined in this document use the default PRF
     for the negotiated TLS version, unless a replacement for the
     default PRF is negotiated by way of a TLS extension.  (While no
     such TLS extension has been defined so far, it is foreseen that a
     need for PRF negotiation might possibly come up.)"

Bodo