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

From: [email-masked]
Date: Mon, 15 Nov 2004 13:19:25 +0200

Peter Gutmann wrote:
> [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.

I'm not sure if we should call it a "general-purpose" mechanism,
but I don't have any problem doing it the same way for all the
ciphersuites in this document.

Would something like this be better than the current text?

Section 2 (plain PSK case):
  
   The premaster secret is formed as follows: if the PSK is N
   octets long, concatenate an uint16 with the value N, N zero
   octets, a second uint16 with the value N, and the PSK itself.

      Note 1: All the ciphersuites in this document share the
      same general structure for the premaster secret, namely
      "opaque other_secret<0..2^16-1>; opaque psk<0..2^16-1>;".
      Here "other_secret" is either zeroes (plain PSK case), or
      comes from the Diffie-Hellman or RSA exchange (DHE_PSK and
      RSA_PSK, respectively). See Sections 3 and 4 for a more
      detailed description.

      Note 2: Using zeroes for "other_secret" 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.

Section 3 (DHE_PSK case)

   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, an uint16 containing the lengh of the PSK (in
   octets), and the PSK itself.

Section 4 (RSA_PSK case)

   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 an
   uint16 with the value 48, the 2-byte version number and the
   46-byte random value, an uint16 containing the length of the
   PSK (in octets), and the PSK itself.

(Comments from everyone else are also appreciated!)

Best regards,
Pasi

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

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 16 Nov 2004 01:00:46 +1300

>Would something like this be better than the current text?

Yup, that looks fine.

Peter.

---

From: Mohamad Badra <[email-masked]>
Date: Mon, 15 Nov 2004 19:46:38 +0100

Hi list,

IMHO, the draft is well commented and it is actually more clarified. 
Public and private comments were token into account by the authors. Big 
thanks for your comments to the draft and special thanks to Pasi :)

Best regards,
-Bdr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 15 Nov 2004 20:57:10 +0100

> (Comments from everyone else are also appreciated!)
No more comments from me. The current draft is ok with me.

-- 
Nikos Mavrogiannopoulos