Subject: [TLS] TLS-PSK WGLC comments

From: [email-masked]
Date: Thu, 4 Nov 2004 18:11:22 +0200

Hi everyone,

Here's a summary of the comments received during WGLC (thanks
especially to Nikos and Peter for going through the document
quite thoroughly!), together with my proposals on how to 
address them.

I hope to update the document soon after IETF61, so I'd
appreciate comments (even saying that the proposals are
acceptable to you, so we'll know if we have rough consensus 
on this) during the next week or so...

Technical issues:

1. Removing RC4-based ciphersuites?

   Peter Gutmann asked whether the RC4 ciphersuites are
   necessary.  Pasi commented that practically all TLS
   implementations have RC4 anyway, and in some implementations
   RC4 is considerably faster.

   My proposal: No harm in including them, so keep them in.

2. Removing RSA_PSK ciphersuites

   Nikos asked if the RSA_PSK ciphersuites are actually needed
   for anything, but at least Peter thought they would be quite
   useful.

   My proposal: keep them.

3. Adding other combinations like DHE_RSA_PSK and DHE_DSS_PSK

   Nikos also asked by other combinations, like DHE_RSA_PSK or
   DHE_DSS_PSK (or even DH_DSS_PSK, DH_RSA_PSK, ECDH_ECDSA_PSK,
   ECDHE_ECDSA_PSK, ECDH_RSA_PSK, ECDHE_RSA_PSK, and ECDHE_PSK)
   were not included. At least Pasi and Eric thought that there
   is no real need for them, and if a need arises, they can be
   defined in a separate document later (and we should avoid
   unnecessary number space explosion).

   My proposal: Do not include other combinations at this time.
   This does not, of course, prevent us from defining them in a
   separate document later.

4. Empty identity hint

   Currently the draft says that the identity hint can be an
   empty string, but the ServerKeyExchange message is always
   sent even in that case. Peter asked if it would be better to
   omit the whole message in this case. Pasi thought sending the
   message anyway might be simpler, but there's no big
   difference either way.

   My proposal: Keep it as it is (that is, no special case for
   zero-length identity hint).

5. MD5/SHA1 PRF stuff

   Currently the premaster secret for plain PSK ciphersuites is
   "0 || PSK", meaning that only zeroes are fed to the MD5 part
   of the PRF.

   Peter Gutmann commented that "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."

   Hugo Krawczyk commented that from "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."

   Dan Simon replied that "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."

   My interpretation of these comments is that none of the
   proposed alternatives has any real vulnerabilities (so
   choosing any of them would work just fine in practice), and
   the difference is mainly which design principle is considered
   more important (keeping the fail-safe redundancy or
   analytical "elegance").

   I have no strong opinions either way here, but my proposal
   would be to keep it as "0||PSK" as suggested by Hugo and Dan.

6. DHE premaster secret 

   Currently the premaster secret is the DH value and PSK
   concatenated. Peter suggested that it might be better to
   include some length field to remove the possibility for key
   equivalents.

   I tend to agree here, and I propose changing this:
   
      "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."

   To this:

      "The premaster secret is formed as follows. Let Z be the
      value produced by the Diffie-Hellman exchange (with
      leading zero bytes stripped as in other Diffie-Hellman
      based ciphersuites). Concatenate an uint16 containing the
      length of Z (in octets), Z itself, and the PSK, in this
      order."

7. Identity format

   Nikos commented that the draft should be more specific about
   what the identity field contains to improve chances for
   interoperability, and suggested using UTF-8.  Pasi agreed
   that it's important to avoid the situations where both ends
   are using e.g. Distinguished Names, but encode them in a
   different way, or an implementation does not allow an
   administrator to enter the identifier the other end is
   expecting. 

   My proposal (from http://www.imc.org/ietf-tls/mail-archive/
   msg04374.html): Change this

      "This document does not specify the format of the PSK
      identity or PSK identity hint; neither is specified how
      exactly the client uses the hint (if it uses it at all).
      The parties have to agree on the identities when the
      shared secret is configured (however, see Section 6 for
      related security considerations).  In situations where the
      identity is entered by a person, it is RECOMMENDED that
      the input is processed using an appropriate stringprep [9]
      profile and encoded in octets using UTF-8 encoding [14].
      One possible stringprep profile is described in [8]."

   To this:

      "It is expected that different types of identities are
      useful for different applications running over TLS. This
      document does not therefore mandate the use of any
      particular type of identity (such as IPv4 address or FQDN)
      or identity hint; neither is specified how exactly the
      client uses the hint (if it uses it at all).

      To increase the chances for succesful interoperation
      between applications that do agree on what type of
      identity is used, the identity MUST be first converted to
      a character string, and then encoded to octets using UTF-8
      [UTF8]. For instance,

      o  IPv4 addresses are sent as dotted-decimal strings
         (e.g., "192.0.1.2"), not as 32-bit integers in 
         network byte order.

      o  Domain names are sent in their usual text form (e.g.,
         "www.example.com" or "embedded\.dot.example.net"),
         not in DNS protocol wire format.

      o  X.500 Distinguished Names are sent in their string
         representation [draft-ietf-ldapbis-dn-14], not as
         BER-encoded ASN.1.

      In situations where the identity is entered by a person,
      processing the character string with an appropriate
      stringprep [9] profile is RECOMMENDED."
   
8. Ciphersuite and other numbers are TBD

   Nikos and Peter commented that we can't have any
   implementations before we assign the required numbers.  
   Eric suggested that numbers should be picked after WGLC,  
   being very careful to avoid collisions.

   My proposal (from http://www.imc.org/ietf-tls/mail-archive/
   msg04373.html): Use ciphersuite numbers starting from 0x8A 
   and alert number 115.

Editorial comments:

9. Ciphersuite names

   Nikos commented about the ciphersuite names, but I think the
   conclusion of the discussion was that they are reasonably in
   line with other TLS ciphersuites. Thus, I propose keeping the
   current names.

10. Wording about "Dictionary attacks"

   Nikos commented that "I don't think that here "dictionary
   attacks" is appropriate. PSK is not supposed to be a password
   based authentication (as also stated in section 1.1), so
   dictionary attacks do not apply."

   Pasi replied that in some cases, PSKs might be selected by
   humans (instead of generated randomly), and the term
   "dictionary attack" could be used without being too
   inaccurate.

   My proposal is to change this:

      "Use of a fixed shared secret of limited entropy (such as
      a password) may allow an attacker to perform a brute-force
      or dictionary attack to recover the secret. (...) "

   To this:

      "Use of a fixed shared secret of limited entropy (for
      example, a PSK that is relatively short, or was chosen by
      a human and thus may contain less entropy than its length
      would imply) may allow an attacker to perform a
      brute-force or dictionary attack to recover the
      secret. (...)"

11. Possible ambiguity in RSA_PSK premaster description

   I got an off-list question about the RSA_PSK ciphersuites:
   does the client RSA-encrypt only the 48-byte random value, or
   also the PSK? It's only the 48-byte random value, of course,
   but perhaps the text could be reworded a bit.

   My proposal is to change this:

      "The premaster secret is formed as follows: concatenate
      the 48-byte value generated by the client (and sent to the
      server in ClientKeyExchange message) and the PSK, in this
      order."
 
   To this:
      
      "The EncryptedPreMasterSecret field sent from the client
      to the server contains a 2-byte version number and a
      46-byte random value, encrypted using the server's RSA
      public key as described in Section 7.4.7.1 of [3]. The
      actual premaster secret is formed by both parties as
      follows: concatenate the 2-byte version number, the
      46-byte random value, and the PSK, in this order."
      
Best regards,
Pasi

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

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 08 Nov 2004 15:15:02 +1300

[email-masked] writes:

>Currently the premaster secret is the DH value and PSK concatenated. Peter
>suggested that it might be better to include some length field to remove the
>possibility for key equivalents.

What I was really hoping for was a general-purpose:

  opaque premaster<0..2^16-1>;
  opaque psk<0..2^16-1>;

(in my original post I said 'dhValue' rather than 'premaster', which was a bit
misleading).  What I was proposing was a general-purpose mechanism that works
for all algorithm types (straight shared-key, PSK with RSA, PSK with DH, PSK
with quantum tunnelling of key bits...), rather than a special-case one only
for DH.  This is both consistent (it works the same for all algorithms rather
than having special-case handling for different ones, which makes
implementation a lot easier) and capable of handling future algorithm choices
that may require this.

Peter.