Subject: [TLS] While we're patching

From: Watson Ladd <[email-masked]>
Date: Thu, 5 Mar 2015 19:37:00 -0800

Dear all,

Consider https://www.smacktls.com/. It's clear that the implementors
of TLS libraries attempt to minimize codesize by sharing code between
various exchanges but in doing so often mis-implement the state
machine. As we decide to further complicate, not simplify, the state
machine in TLS 1.3, we should strongly consider making the description
of the state machine more formal, and simplifying the flows: mo' code,
mo' problems.

The independence of the implementations suffering these problems
demonstrates that it is the RFC which is at fault. One can only blame
the coders so many times: once the same bug appears twice
independently, it's probably specification issue.

Sincerely,
Watson Ladd

---

From: Yuhong Bao <[email-masked]>
Date: Thu, 5 Mar 2015 20:09:13 -0800

The fact that the Finished hash depended only on the master secret is also part of the problem, to be honest.

> Date: Thu, 5 Mar 2015 19:37:00 -0800
> From: [email-masked]
> To: [email-masked]
> Subject: [TLS] While we're patching
> 
> Dear all,
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 8 Mar 2015 16:01:17 +0200

> of the state machine more formal, and simplifying the flows: mo' code,

Goal: Remove as much redundancy as possible, since redumdancy is
_infamous_ source of (security) bugs[1].

Idea: Make all handshake message types implicit[2], forcing
implementations to do the right thing and track message types
properly (obviously no message can be optional afterwards, but
situation-dependent messages are possible).

Also, instead of restarting the handshake (turns out this won't
work as well as initially seems) just have client send exchange blob
(with no group identifier, since the correct one was already sent).

This will also narrow the gap between minimal workign and minimal
secure complexity (and seemingly not increase actual complexity)[3].

Potential downside is handling extensions (especially if multiple
are used at once) that want to send their own messages (besides
just the two extension negotiation blobs).

[1] It is also the cause of the SMACK-like bugs found in _multiple_
TLS stacks.

[2] For backwards compatiblity ClientHello has to have 1 where the
type field goes and ServerHello has to have 2 where the type goes.

[3] Difference between minimum working complexity and minimum
secure complexity should be as small as possible, since it
is another name for implementation pitfalls, and have that
be big enough and a lot of implementations WILL (not may)
fall into those (this has been shown plenty of times already).

-Ilari