Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets

[Maarten Bodewes]

Hi David,

Great. Thanks for following up on this!

I think I now understand why the implementation of DH seemed buggy in one
of the crypto libraries that I was reviewing.

Regards,
Maarten
Op 19 mei 2016 21:22 schreef "David Benjamin" :

> If the WG agrees with this change, I've put together a PR here:
> https://github.com/tlswg/tls13-spec/pull/462
>
> On Tue, May 17, 2016 at 4:14 PM David Benjamin 
> wrote:
>
>> Reviving this thread, I also think it would also be a good idea if 1.3
>> did not stripping zeros from Z. Having this logic is rather dubious w.r.t.
>> treating secret data in constant-time. And as Bill Cox mentioned
>> elsewhere in this thread, this odd behavior has caused interoperability
>> issues in the past.
>>
>> I don't think we have to be worried about inconsistency with 1.2 as, by
>> the time this happens, we will already know we're speaking 1.3. TLS 1.3 DHE
>> is already a very different beast from TLS 1.2 DHE. At this point, the only
>> thing they meaningfully share is they happen to use the same code points.
>>
>> David
>>
>> On Thu, Apr 7, 2016 at 10:37 AM Russ Housley 
>> wrote:
>>
>>> I would prefer to always use the full, known-length byte string for Z.
>>> In my experience, it is better to know the lengths of byte strings instead
>>> of stripping leading zeroes.  The difference in the speed of the HKDF
>>> computation by omitting the leading zeros is not significant.  Alignment
>>> with NIST SP 800-56A is nice, but it is not the reason for my preference.
>>>
>>> Russ
>>>
>>>
>>> On Mar 28, 2016, at 11:56 AM, Maarten Bodewes 
>>> wrote:
>>>
>>> > Hi all,
>>> >
>>> > I see that the leading zero is stripped off of the value of Z (the
>>> shared secret) before it is used as input to HKDF. This seems to be
>>> compatible with TLS 1.2. Then again, it is not compatible with e.g.
>>> NISP800-56A which uses the value of Z with the same size of the prime in
>>> octets. Furthermore, it is also different with regards to handling the
>>> coordinate X as used in ECDH.
>>> >
>>> > Was this a conscious decision to keep compatibility with TLS? Has the
>>> use of the value of Z including zero octets been considered?
>>> >
>>> > Regards,
>>> > Maarten
>>>
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets

[Russ Housley]

Thanks for doing the text.

Russ


On May 19, 2016, at 3:22 PM, David Benjamin  wrote:

> If the WG agrees with this change, I've put together a PR here:
> https://github.com/tlswg/tls13-spec/pull/462
> 
> On Tue, May 17, 2016 at 4:14 PM David Benjamin  wrote:
> Reviving this thread, I also think it would also be a good idea if 1.3 did 
> not stripping zeros from Z. Having this logic is rather dubious w.r.t. 
> treating secret data in constant-time. And as Bill Cox mentioned elsewhere in 
> this thread, this odd behavior has caused interoperability issues in the past.
> 
> I don't think we have to be worried about inconsistency with 1.2 as, by the 
> time this happens, we will already know we're speaking 1.3. TLS 1.3 DHE is 
> already a very different beast from TLS 1.2 DHE. At this point, the only 
> thing they meaningfully share is they happen to use the same code points.
> 
> David
> 
> On Thu, Apr 7, 2016 at 10:37 AM Russ Housley  wrote:
> I would prefer to always use the full, known-length byte string for Z.  In my 
> experience, it is better to know the lengths of byte strings instead of 
> stripping leading zeroes.  The difference in the speed of the HKDF 
> computation by omitting the leading zeros is not significant.  Alignment with 
> NIST SP 800-56A is nice, but it is not the reason for my preference.
> 
> Russ
> 
> 
> On Mar 28, 2016, at 11:56 AM, Maarten Bodewes  
> wrote:
> 
> > Hi all,
> >
> > I see that the leading zero is stripped off of the value of Z (the shared 
> > secret) before it is used as input to HKDF. This seems to be compatible 
> > with TLS 1.2. Then again, it is not compatible with e.g. NISP800-56A which 
> > uses the value of Z with the same size of the prime in octets. Furthermore, 
> > it is also different with regards to handling the coordinate X as used in 
> > ECDH.
> >
> > Was this a conscious decision to keep compatibility with TLS? Has the use 
> > of the value of Z including zero octets been considered?
> >
> > Regards,
> > Maarten
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets

[David Benjamin]

If the WG agrees with this change, I've put together a PR here:
https://github.com/tlswg/tls13-spec/pull/462

On Tue, May 17, 2016 at 4:14 PM David Benjamin 
wrote:

> Reviving this thread, I also think it would also be a good idea if 1.3 did
> not stripping zeros from Z. Having this logic is rather dubious w.r.t.
> treating secret data in constant-time. And as Bill Cox mentioned
> elsewhere in this thread, this odd behavior has caused interoperability
> issues in the past.
>
> I don't think we have to be worried about inconsistency with 1.2 as, by
> the time this happens, we will already know we're speaking 1.3. TLS 1.3 DHE
> is already a very different beast from TLS 1.2 DHE. At this point, the only
> thing they meaningfully share is they happen to use the same code points.
>
> David
>
> On Thu, Apr 7, 2016 at 10:37 AM Russ Housley  wrote:
>
>> I would prefer to always use the full, known-length byte string for Z.
>> In my experience, it is better to know the lengths of byte strings instead
>> of stripping leading zeroes.  The difference in the speed of the HKDF
>> computation by omitting the leading zeros is not significant.  Alignment
>> with NIST SP 800-56A is nice, but it is not the reason for my preference.
>>
>> Russ
>>
>>
>> On Mar 28, 2016, at 11:56 AM, Maarten Bodewes 
>> wrote:
>>
>> > Hi all,
>> >
>> > I see that the leading zero is stripped off of the value of Z (the
>> shared secret) before it is used as input to HKDF. This seems to be
>> compatible with TLS 1.2. Then again, it is not compatible with e.g.
>> NISP800-56A which uses the value of Z with the same size of the prime in
>> octets. Furthermore, it is also different with regards to handling the
>> coordinate X as used in ECDH.
>> >
>> > Was this a conscious decision to keep compatibility with TLS? Has the
>> use of the value of Z including zero octets been considered?
>> >
>> > Regards,
>> > Maarten
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets

[David Benjamin]

Reviving this thread, I also think it would also be a good idea if 1.3 did
not stripping zeros from Z. Having this logic is rather dubious w.r.t.
treating secret data in constant-time. And as Bill Cox mentioned elsewhere
in this thread, this odd behavior has caused interoperability issues in the
past.

I don't think we have to be worried about inconsistency with 1.2 as, by the
time this happens, we will already know we're speaking 1.3. TLS 1.3 DHE is
already a very different beast from TLS 1.2 DHE. At this point, the only
thing they meaningfully share is they happen to use the same code points.

David

On Thu, Apr 7, 2016 at 10:37 AM Russ Housley  wrote:

> I would prefer to always use the full, known-length byte string for Z.  In
> my experience, it is better to know the lengths of byte strings instead of
> stripping leading zeroes.  The difference in the speed of the HKDF
> computation by omitting the leading zeros is not significant.  Alignment
> with NIST SP 800-56A is nice, but it is not the reason for my preference.
>
> Russ
>
>
> On Mar 28, 2016, at 11:56 AM, Maarten Bodewes 
> wrote:
>
> > Hi all,
> >
> > I see that the leading zero is stripped off of the value of Z (the
> shared secret) before it is used as input to HKDF. This seems to be
> compatible with TLS 1.2. Then again, it is not compatible with e.g.
> NISP800-56A which uses the value of Z with the same size of the prime in
> octets. Furthermore, it is also different with regards to handling the
> coordinate X as used in ECDH.
> >
> > Was this a conscious decision to keep compatibility with TLS? Has the
> use of the value of Z including zero octets been considered?
> >
> > Regards,
> > Maarten
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets

[Russ Housley]

I would prefer to always use the full, known-length byte string for Z.  In my 
experience, it is better to know the lengths of byte strings instead of 
stripping leading zeroes.  The difference in the speed of the HKDF computation 
by omitting the leading zeros is not significant.  Alignment with NIST SP 
800-56A is nice, but it is not the reason for my preference.

Russ


On Mar 28, 2016, at 11:56 AM, Maarten Bodewes  wrote:

> Hi all,
> 
> I see that the leading zero is stripped off of the value of Z (the shared 
> secret) before it is used as input to HKDF. This seems to be compatible with 
> TLS 1.2. Then again, it is not compatible with e.g. NISP800-56A which uses 
> the value of Z with the same size of the prime in octets. Furthermore, it is 
> also different with regards to handling the coordinate X as used in ECDH.
> 
> Was this a conscious decision to keep compatibility with TLS? Has the use of 
> the value of Z including zero octets been considered?
> 
> Regards,
> Maarten

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets

[Peter Gutmann]

Bill Cox  writes:

>I spent 2 weeks last year tracking down a flaky bug that only occurs once in
>every 256 connection: the leading 0 byte was no longer being stripped in a
>code change I ported from OpenSSL master, and only Maria DB ran random tests
>enough to trigger this condition.

My self-test code includes 1K iterations of various PKC ops in mechanisms that
are sensitive to leading-zero truncation (PGP springs to mind) to detect this.
Without this, it's mostly blind luck as to whether your self-test hits the
1/256 one that triggers the problem.  Having to design coverage tests is hard
enough, but when you need to iterate them to find problems...

Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets

[Maarten Bodewes]

Hi all,

I see that the leading zero is stripped off of the value of Z (the shared
secret) before it is used as input to HKDF. This seems to be compatible
with TLS 1.2. Then again, it is not compatible with e.g. NISP800-56A which
uses the value of Z with the same size of the prime in octets. Furthermore,
it is also different with regards to handling the coordinate X as used in
ECDH.

Was this a conscious decision to keep compatibility with TLS? Has the use
of the value of Z including zero octets been considered?

Regards,
Maarten
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls