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

From: [email-masked]
Date: Mon, 11 Oct 2004 13:17:53 +0300

Peter Gutmann <[email-masked]> writes:
>
> D'oh, just after I finally got round to typing up some comments:

Thanks for your comments, Peter!

>   TLS_PSK_WITH_RC4_128_SHA
>   TLS_DHE_PSK_WITH_RC4_128_SHA
>   TLS_DHE_PSK_WITH_RC4_128_SHA
> 
> Is there a need for this SSLv2-era legacy cipher?  The only reason
> it's present in current implementations (and hardware) is for
> backwards-compatibility.  In addition it's not a FIPS algorithm,
> so it can't be used in environments where certification is required.  
> I can see that it'd be useful in low-resource environments (one 
> of the main motivations for PSK TLS), but wouldn't AES take care 
> of that?

Practically all TLS implementations have it, and in some libraries
(e.g. Crypto++ and OpenSSL) RC4 is over twice as fast as AES.  Your
mileage may, of course, vary, but I don't see any harm in including 
it either.

>   (note that if no hint is provided, a ServerKeyExchange 
>   message is still sent)
> 
> Wouldn't it be better to omit this message than to send a message
> whose only purpose is to indicate that the page is intentionally
> left blank?

Maybe less alternatives in the code path (or fewer transitions 
in a "state machine" like implementation)? But it probably 
doesn't matter that much either way...

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

>   The premaster secret is formed as follows: concatenate the 
>   value produced by the Diffie-Hellman exchange (with leading 
>   zero bytes stripped as in other Diffie-Hellman based ciphersuites) 
>   and the PSK, in this order.
> 
> Wouldn't it be better to concat:
> 
>   opaque dhValue<0..2^16-1>;
>   opaque psk<0..2^16-1>;
> 
> rather than the raw components?  Otherwise you get a pile of
> key-equivalents depending on where you draw the line between the DH
> value and the PSK.  So [ DH-value...XX || YY ] is equivalent to 
> [ DH-value || XX YY ].  Now admittedly this shouldn't be much of an
> issue because DH-value will always change by a large amount each
> time, but it'd still be better to define a uniform premaster
> generation process that takes as input the existing secret value
> (whether it be generated via RSA, DH, or anything else) as a vector
> and concatenates the PSK as a vector.  This is a universal mechanism
> that applies to any key exchange algorithm that may be used
> (Fortezza, etc etc).

I see your point... though I don't see any advantage doing
this for RSA_PSK, since the first part is always 48 octets.
And even in DH, the DH-value has always almost the same 
length as p.

(Any other opinions on this? Should we add a length field here?)

>   (This depends on whether this document is published before 
>   or after TLS 1.1.)
> 
> Can we get this sorted out?  After I published my PSK draft I had
> a number of requests from people who wanted to get a shared-key
> mechanism into production as quickly as possible, at the moment with
> everything listed as TBD you can't even do a test implementation
> from it.  In fact why do the cipher suites depend on when TLS 1.1 is
> published?  Unless they're going to be defined in the TLS 1.1 spec,
> there's only one form of the text that's required.

If this draft is published after TLS 1.1, the ciphersuite numbers 
have to be assigned by IANA... (though the current version of 
2246bis doesn't actually say when this happens; it probably 
should say "Standards Action" for the 0..191 range)

Best regards,
Pasi

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

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 12 Oct 2004 03:17:52 +0200 (IST)

>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

> > Argh, no, this is just wrong!Even if using half the PRF is
> > it was flagged as a flaw by people commenting on it).The MD5
> > by doing this.The calculation should use both parts of the PRF,