Subject: RE: [TLS] TLS-PSK WGLC comments

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 16 Nov 2004 14:51:48 +0100

hi pasi, 

thanks for summarizing all issues raised during wglc. the proposed
resolution for each of them is fine with me. thanks for the great work!

ciao
hannes

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Donnerstag, 04. November 2004 17:11
> To: [email-masked]
> Subject: [TLS] TLS-PSK WGLC comments
> 
> 
> 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
> 

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