Re: [TLS] PRF proposal

[Bodo Moeller <bmoeller@xxxxxxx>]

On Mon, Nov 20, 2006 at 09:51:57AM -0500, Blumenthal, Uri wrote:

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

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


Pasi.Eronen@xxxxxxxxx:

> 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)".
[...]
> 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


_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls