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

From: [email-masked]
Date: Thu, 7 Oct 2004 09:40:27 +0300

(No protocol changes, only some clarifications based on comments
we've received -- see Appendix A for a change log.)

---------- Forwarded message ----------
Date: Wed, 06 Oct 2004 15:41:46 -0400
From: [email-masked]
To: [email-masked]
Subject: I-D ACTION:draft-ietf-tls-psk-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the IETF.

	Title		: Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
	Author(s)	: P. Eronen, H. Tschofenig
	Filename	: draft-ietf-tls-psk-02.txt
	Pages		: 14
	Date		: 2004-10-6
	
This document specifies three sets of new ciphersuites for the
   Transport Layer Security (TLS) protocol to support authentication
   based on pre-shared keys.  These pre-shared keys are symmetric keys,
   shared in advance among the communicating parties.  The first set of
   ciphersuites uses only symmetric key operations for authentication.
   The second set uses a Diffie-Hellman exchange authenticated with a
   pre-shared key; and the third set combines public key authentication
   of the server with pre-shared key authentication of the client.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-02.txt

<snip>

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

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 10 Oct 2004 06:51:53 +1300

[email-masked] writes:

>(No protocol changes, only some clarifications based on comments we've
>received -- see Appendix A for a change log.)

D'oh, just after I finally got round to typing up some comments:

  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?

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

  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.

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

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

Peter.