Subject: RE: [TLS] Re: PSK question

From: [email-masked]
Date: Wed, 8 Dec 2004 19:31:10 +0200

Peter Gutmann wrote:
> 
> Another thing I just noticed:
> 
>   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.
> 
> What's the point of the N zero octets?  If other_secret is 
> empty (which it is for the simplest case where there's no DH, 
> RSA, or other keying material present) then shouldn't the:
> 
>   opaque other_secret<0..2^16-1>;
> 
> just be a 16-bit length of zero and no data octets?  Why the 
> unnecessary zero octets?

This was already discussed earlier, see e.g. issue #5 in 
http://www.imc.org/ietf-tls/mail-archive/msg04389.html and
http://www.imc.org/ietf-tls/mail-archive/msg04098.html. 

BR,
Pasi

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

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 09 Dec 2004 15:38:01 +1300

>http://www.imc.org/ietf-tls/mail-archive/msg04098.html.

That was a somewhat different discussion, my concern there was that the MD5
half was being fed all zeroes.  Whether you feed it explicit all-zeroes
(required by the current "zeroes || PSK" construct) or implicit all-zeroes
(from "PSK" with the LHS set to zeroes) shouldn't make any difference...
hmm, OK maybe the explicit-zeroes is more explicit, there just seemed to be a 
lot of unnecessary extra messing with the input required to format the data
this way, whereas simply feeding the PSK straight to the PRF without extra
processing seemed cleaner.

Peter.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 14 Dec 2004 14:20:36 -0800

Peter, do you have a strong objection to this proceeding as-is
or do you just find it mildly unaesthetic?

If the second, I'd like to call it soup.

-Ekr

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 15 Dec 2004 18:44:11 +1300

EKR <[email-masked]> writes:

>Peter, do you have a strong objection to this proceeding as-is or do you just
>find it mildly unaesthetic?

I'm not keen on the PSK kludging when it's fed into the PRF but I guess I can
live with that, however I'd really like to have the server keyex/identity hint
made optional.  Except for one extremely obscure situation (the 3GPP thing
that Pasi mentioned), implementors won't even know what they're supposed to do
with this facility, let alone be able to use it.  All it's doing is
unnecessarily complicating the code on both the client and server, and
bloating up the handshake message size.

Peter.