Re: [TLS] Pull Request: Removing the AEAD explicit IV

[Ilari Liusvaara <[e-mail]>]

On Thu, Mar 19, 2015 at 10:55:54AM -0700, Watson Ladd wrote:
> On Mar 19, 2015 10:40 AM, "Ilari Liusvaara" <[e-mail]>
> wrote:
> >
> > On Thu, Mar 19, 2015 at 09:20:54AM -0700, Watson Ladd wrote:
> > > On Thu, Mar 19, 2015 at 4:33 AM, Brian Smith <[e-mail]>
> wrote:
> > > > Watson Ladd <[e-mail]> wrote:
> > > >> If we're going to make a change this
> > > >> radical, why not make equally radical changes to simplify the
> protocol
> > > >> further if that's possible?
> > > >
> > > > That's already happening.
> > >
> > > No it's not: the draft is still longer than the TLS 1.2 RFC, and seems
> > > to demand support for every single usecase. This seems at odds with
> > > absolute simplification, where we would throw out less important
> > > features, and radically reduce the complexity.
> >
> > Got examples of features that could be removed or at least rendered
> > truly optional (besides things like 0RTT[1])?
> 
> Update: most connections are short-lived. Changing client auth state during
> a connection: restarting works fine. The 1 RTT idea being proposed involves
> remembering unnecessary state.

Update as an extension?

I think splitting the secrets for both directions is a good idea: The
secrets can be derived just before being needed (which cuts down oppurtunity
for errors) and one can just derive the symmetric keys from both.


Additionally, changing client auth state during a connection can be very
dangerous (it depends on protocol riding on top and the context it runs
in).

Client-to-server IRCS? OK. HTTP/2 from web browser? Ouch.
 
> AGL mentioned the ability to have fragmentation of Client Hellos in the
> record layer.

Doesn't seem to be really needed, except for certificate messages. No
other messages seem to be large enough to warrant record-layer fragmentation
under reasonable conditions.

Heck, even dh8k keyshare message (which is likely the largest handshake
message in practice aside of certificates) easily fits inside one IPv6
minMTU datagram, complete with all the needed headers.

> > Unfortunately, to fix the TLS handshaking mechanism, calls for handshake
> > totally different from one TLS 1.2 has.
> 
> This should be doable without increasing the complexity of current code
> that much. The issue with the handshake isn't so much the parsing (
> although nested length encoding is a bad idea, compared to length encoded
> tokens) but the state machine. Adding new transitions and states carefully
> shouldn't be too bad.
> 
> Most implementations already keep a ruuning hash, so the enhanced handshake
> prorocol can fit in. We should tighten up the description significantly,
> explaining exactly which steps are expected when.

Agreed, the endpoints should always know what is to be sent or received
next (and anything else is an protocol error).

A few weeks back I tried to construct a state machine for TLS 1.3. The
nasty problem I ran into was handling the handshake "restart" (the
state machine can't ever be allowed to loop). Also, client certificate
handling caused problems.



-Ilari