Subject: RE: [TLS] draft-chudov-cryptopro-tlsprfneg-00.txt

From: [email-masked]
Date: Mon, 6 Jun 2005 14:42:48 +0300

Gregory S. Chudov wrote:
> 
> Greetings.
> Unfortunately, TLS does not allow a ciphersuite to choose a 
> different PRF.
> 
> Quote from rfc2246:
> 
>    HMAC can be used with a variety of different hash algorithms. 
>    TLS uses it in the handshake with two different algorithms: 
>    MD5 and SHA-1, denoting these as HMAC_MD5(secret, data) 
>    and HMAC_SHA(secret, data). Additional hash algorithms can 
>    be defined by cipher suites and used to protect record data, 
>    but MD5 and SHA-1 are hard coded into the description of the 
>    handshaking for this version of the protocol.
> 
> So adding a cipher suite, which uses different PRF means 
> breaking a protocol. Such cipher suites will not be "legitimate" 
> without the  support and analysis from this working group.

I fully agree: a ciphersuite cannot (and definitely should not)
just decide by itself to change that part of RFC 2246. But if 
we (TLS WG) decide to work on alternative PRFs, we will anyway 
need a document that updates this part of RFC 2246/2246bis 
somehow. 

The main alternatives seem to be defining PRF to be a property
that can be negotiated separately from the ciphersuite (and thus
we need a new negotiation mechanism, as proposed in your draft),
or defining PRF to be associated with the ciphersuite (so we can
use the existing ciphersuite negotiation, as I proposed in my
previous email). Both work, but both also change RFC 2246; 
IMHO the latter approach might be a bit simpler...

Best regards,
Pasi

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

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 27 Jun 2005 06:35:30 +0200

> IMHO the latter approach might be a bit simpler...

My take on this would be that explicit PRF negotiation is probably not
worth the protocol complication.  The Hash/PRF negotiation ID already
points out the potential danger of rollback attacks if a server allows
too much flexibility.

Sometimes, in rare cases, the standard TLS approach does quite not
work for the specific needs of an individual ciphersuite (e.g. for the
pre-shared key setting).  The best way here is, in my opinion, to
format the data in such a way that it can be fed into the standard TLS
PRF.

Actually I don't really like the current TLS PRF design too much.  But
the correct upgrade path to me is to replace the PRF in a future
version of the TLS protocol, and to do so in an identical way for all
ciphersuites.