Subject: RE: [TLS] Fwd: I-D ACTION:draft-ietf-tls-psk-02.txt

From: "Dan Simon" <[email-masked]>
Date: Mon, 11 Oct 2004 18:42:25 -0700

I believe I'm the guy who originally suggested the current parallel
construction of the PRF.  At the time, I explicitly stated that the
whole business of using two fixed hash functions (instead of a single
function specified in the ciphersuite) was a stupid idea, and that I was
only proposing the parallel construction because certain people were
absolutely dead-set on the idea of using both MD5 and SHA1 in the PRF.
So naturally I'm all in favor of Hugo's proposal.  Perhaps one day we
can get rid of the MD5 half altogether, and then make the hash function
used in the second half depend on the ciphersuite, so that SHA1 will
become replaceable, if necessary, merely by defining a new set of
ciphersuites.

				Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hugo Krawczyk
Sent: Monday, October 11, 2004 6:18 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [TLS] Fwd: I-D ACTION:draft-ietf-tls-psk-02.txt

>From a purely analytical point of view using 0||PSK is better than
PSK||PSK (as explained in my January's message referenced below).
Heuristically, your guess is as good as mine.

Hugo

>
> > Note: This effectively means that only the HMAC-SHA1 part (but not 
> > the HMAC-MD5 part) of the TLS PRF is used when constructing the 
> > master secret. See [7] for a more detailed rationale.
> >
> > Argh, no, this is just wrong!Even if using half the PRF is 
> > considered secure, it's just bad engineering practice to take a 
> > security mechanism with fail-safe redundancy built in and throw away

> > the redundancy (this was exactly what my draft initially did, and it

> > was flagged as a flaw by people commenting on it).The MD5 
> > calculation is being performed anyway, so you're not saving anything

> > by doing this.The calculation should use both parts of the PRF, to 
> > match its usage everywhere else in TLS.
>
> I agree there's no saving in CPU costs; it was done this way because 
> when Hugo Krawczyk commented your draft in January, he suggested that 
> it should be done this way.
> (http://www.imc.org/ietf-tls/mail-archive/msg04098.html)
>
> But I'm open to changing this if the WG thinks so (one
> likely alternative would be to use "PSK || PSK").
>

_______________________________________________
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: Russ Housley <[email-masked]>
Date: Sat, 23 Oct 2004 15:06:03 -0400

The PRF is not currently negotiated as part of the cipher suite.  However, 
the draft-ietf-tls-gost-00.txt draft proposes a way to negotiate the PRF, 
but it is done independently from the rest of the algorithm negotiations.

Given that at least one person other than the GOST algorithm specification 
authors is interested in PRF negotiation, I would like to see a discussion 
about this topic.  Have the GOST algorithm specification authors done this 
in the best possible way?  What are the alternatives?

The GOST algorithm specification authors' proposal also has an impact on 
the Finished message.  This leads to other questions.  Can one negotiate 
which hash function to use when that hash function is in turn used to 
protect the integrity of the whole algorithm negotiation process?

Russ