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

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Thu, 19 March 2015 17:40 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 9C67D1A86FE for <tls@ietfa.amsl.com>; Thu, 19 Mar 2015 10:40:07 -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 GizIZo-2efBO for <tls@ietfa.amsl.com>; Thu, 19 Mar 2015 10:40:04 -0700 (PDT)
Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5FA1A8033 for <tls@ietf.org>; Thu, 19 Mar 2015 10:40:04 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id B37BB1887AC; Thu, 19 Mar 2015 19:40:01 +0200 (EET)
Date: Thu, 19 Mar 2015 19:40:01 +0200
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Watson Ladd <watsonbladd@gmail.com>
Message-ID: <20150319174001.GA3690@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CACsn0cm09x9oHynJc0FU78TQcdh5EPc2sAbahNSEuLw9nNAeXg@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/AboIUoiL3wG9Lmg0B3e7tBxKtbA>
Cc: "tls@ietf.org" <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 17:40:07 -0000

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])?

> > 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.



[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