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

[Watson Ladd <[e-mail]>]

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.

AGL mentioned the ability to have fragmentation of Client Hellos in the
record layer.

>
> > > Also, the proposed changes to the handshake state machine for TLS 1.3
> > > are much larger. It seems we can't substantially simplify the protocol
> > > proportionately increasing the complexity of implementations that need
> > > to also implement earlier versions.
> >
> > Adding new states and transitions to a state machine doesn't increase
> > complexity that much: if the transition doesn't apply, you don't take
> > it. But adding additional special casing all over the place to deal
> > with TLS 1.3 does increase complexity much more.
>
> Unfortunately, to fix the TLS handshaking mechanism, calls for handshake
> totally different from one TLS 1.2 has.
>
> The overall architecture of TLS 1.3 handshake looks good to me, the
> divisions it makes look to harden the handshake a lot against various
> attacks. Unfortunately, the handshake currently looks to have rather large
> implementation security gap.
>
> Additionally, in practice, the capablity to send a handshake that can
> be downnegotiated is needed.

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.

Sincerely,
Watson Ladd

>
>
>
> [1] If 0RTT was an extension with positive acknowledgement, server could
> just leave it unimplemented and things would still work, albeit possibly
> with extra RTT.
>
>
>
> -Ilari