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

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Thu, 19 March 2015 18:31 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080E91A87AB for <tls@ietfa.amsl.com>; Thu, 19 Mar 2015 11:31:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqLdZDLkYE3a for <tls@ietfa.amsl.com>; Thu, 19 Mar 2015 11:31:08 -0700 (PDT)
Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB90E1A8AB4 for <tls@ietf.org>; Thu, 19 Mar 2015 11:31:07 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 70E21817FB; Thu, 19 Mar 2015 20:31:05 +0200 (EET)
Date: Thu, 19 Mar 2015 20:31:05 +0200
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Watson Ladd <watsonbladd@gmail.com>
Message-ID: <20150319183105.GA4192@LK-Perkele-VII>
References: <CABcZeBPfasM5HmJaATLUHQKRgiSGCreJt1T=UoDBGCbcuzyW8Q@mail.gmail.com> <CAAF6GDdbr57hVa4OD-wCfQtx46bo_D858V_25w8gTtd+M8OhzQ@mail.gmail.com> <CACsn0ckU==QcJhTvyov2DeJCKq_kxvfqK=AkFKsyFcRbQBfC-Q@mail.gmail.com> <CAFewVt6ay5ti9EJRsAm0fLSFjyBHCg_BM0P2DbKHwDxcEWxOmQ@mail.gmail.com> <CACsn0cm09x9oHynJc0FU78TQcdh5EPc2sAbahNSEuLw9nNAeXg@mail.gmail.com> <20150319174001.GA3690@LK-Perkele-VII> <CACsn0cm-8jyZHDa11ya5nRBAYXZc9EF354eAyZu3ND0usVTrsg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CACsn0cm-8jyZHDa11ya5nRBAYXZc9EF354eAyZu3ND0usVTrsg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/pubHL1PyoHWZ_Oje_Wxfgt5Mw0Y>
Cc: tls@ietf.org
Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Mar 2015 18:31:14 -0000

On Thu, Mar 19, 2015 at 10:55:54AM -0700, Watson Ladd wrote:
> On Mar 19, 2015 10:40 AM, "Ilari Liusvaara" <ilari.liusvaara@elisanet.fi>;
> 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 <brian@briansmith.org>;
> wrote:
> > > > Watson Ladd <watsonbladd@gmail.com>; 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