Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Maarten Bodewes]

Hi all,

The point is we are now indeed on draft 18. Changing the name now is very
problematic because everybody on the mailinglist already calls it TLS 1.3,
for a long time and no matter what you do, a lot of us (who are hopefully
the experts) will keep referring to it under that name.

If you want a name change, introduce it early (as editor of the RFC, these
guys should be able to make this kind of decision) or otherwise keep the
name.

The same kind of discussion was on the SHA-3 mailing list, where some
argued for AHS instead of SHA-3. The same problem ensued there and SHA-3
was kept in the end (although I don't know how the decision was made at
that time).

Further discussions continue at s...@ietf.org ;)

Regards,
Maarten

2016-12-02 15:54 GMT+01:00 Ted Lemon :

> The bottom line is that this is an unanswerable question.   My advice
> is to not change the name, because I think more name changes = more
> confusion and it is _way_ too late to put TLS back in the box.   But
> what do I know--I'm just an end user!   :)
>
> On Fri, Dec 2, 2016 at 9:42 AM, Hubert Kario  wrote:
> > On Friday, 2 December 2016 14:12:38 CET Salz, Rich wrote:
> >> > SSL 2 < SSL 3 < "SSL" 1.0 < "SSL" 1.1 < "SSL" 1.2 < "SSL" 4 is not
> logical
> >> > ordering
> >>
> >> So?  Who cares?  A couple-hundred people in the IETF.  And the issue is
> that
> >> SSL 3 < "SSL" 1.0 which is the issue no matter what we call what we're
> >> doing here.  And the quotes around the last SSL do not belong there.
> >
> >> You can say that calling it "TLS 1.3" promulgates the illogical
> ordering, or
> >> you could say it continues a renumbering.  A renumbering that the world
> has
> >> never recognized or understood.  You can say that "SSL 4" confuses
> people
> >> twice, or you can say that it restores sanity to a 20-year glitch and
> >> starts us using the same name that the rest of the world, *and our
> >> industry,* uses.
> >
> > what it does is it introduces a second glitch
> >
> > speaking of confusion, do you know that e-mail clients by "SSL" mean
> "SSL/TLS"
> > and by "TLS" mean "STARTTLS"?
> > (note the port numbers)
> > https://sils.unc.edu/it-services/email-faq/outlook
> > https://mail.aegee.org/smtp/kmail.html
> > https://sils.unc.edu/it-services/my-computer/email-faq/thunderbird
> >
> > --
> > Regards,
> > Hubert Kario
> > Senior Quality Engineer, QE BaseOS Security team
> > Web: www.cz.redhat.com
> > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
> >
> > ___
> > 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
>
___
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

[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" <david...@chromium.org>:

> 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 <david...@chromium.org>
> 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 <hous...@vigilsec.com>
>> 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 <maarten.bode...@gmail.com>
>>> 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

[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