Re: [TLS] Pre-master secret formatting for master secret calculation with DH in TLS 1.x

Thank you, Martin. I will assume that the TLS >= 1.1 style it the right 
way to encode the shared secret of the DH exchange.

This seems like an odd way to represent a finite field element with 
implicit length. Unlike strings, here we know the maximum size.

On 02/08/2013 11:23 AM, Martin Rex wrote:
> It appears to have been retroactively clarified as being (2)
> from your choices:
>
> TLSv1.1   http://tools.ietf.org/html/rfc4346#section-8.1.2
> TLSv1.2   http://tools.ietf.org/html/rfc5246#section-8.1.2
>
>                                          Leading bytes of Z that
>     contain all zero bits are stripped before it is used as the
>     pre_master_secret.
>
> -Martin
>
> Andrey Jivsov wrote:
>> I ran into an interoperability problem between our TLS implementation
>> and another very popular one.
>>
>> The question is what exactly is the formatting  for the RFC2246 sec.
>> 8.1.2 "Diffie-Hellman" shared secret 'Z' ?
>>
>> The problem arises when the most significant byte of the Z is zero.
>> Let's say that the field prime's size is 256. There are two possibilities:
>>
>> 1. export the Z in the big endian format, padding it to 256 (first byte
>> in the buffer is zero)
>> 2. export the Z in the big endian format, placing the result in a 255
>> byte buffer.
>>
>> I would say that this should be #1, because it is the natural
>> representation of the Z. If there is a language specifying the canonical
>> encoding for the Z, I would appreciate the reference.
>>
>> ( Apparently, this problem doesn't clearly manifest itself in real
>> deployments because ~ the 1/256 failure rate is masked by
>> re-negotiations at the higher protocol level. )
>>
>> Thank you.
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls