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

Watson Ladd <watsonbladd@gmail.com> Thu, 19 March 2015 17:55 UTC

Return-Path: <watsonbladd@gmail.com>
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 E75731A87E3 for <tls@ietfa.amsl.com>; Thu, 19 Mar 2015 10:55:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 NXfwYYDvTTup for <tls@ietfa.amsl.com>; Thu, 19 Mar 2015 10:55:55 -0700 (PDT)
Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D95B1A8778 for <tls@ietf.org>; Thu, 19 Mar 2015 10:55:55 -0700 (PDT)
Received: by yhch68 with SMTP id h68so29179599yhc.1 for <tls@ietf.org>; Thu, 19 Mar 2015 10:55:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FGvApu22WwqeZ50tATUpLQNgJ9JOL1Ghc92IqoMt1Mw=; b=pqPgcd9CU7muA1WckMY+VZlB7wbyfMSkhr9PVbMLOpE0Qx83UsuJhvFfZeKKBwunzA 6Dw/PHNOkMWm+0CxksE/4joB/m1lhieNIhQMi0n59jT93rQDg0sp6ajf6yUB8OjPitWr qCjalWw3jK+a0mHO7Vp0Eo9teQT/RA0W9bXS0xb1YFlZBhZEpPw2RG1v3HmUrefZ4Uk8 Km529bAzLYFPLLkFvaAeCxLD1DbCmjZldu6WPmPFDgxDnnF647Mm4h0cmHzdp4ld1nZK jnKFqisioNkx/Ub7UYeDrv9u8mHJomNgFm11S7PPVvsTWjY+9+KUgBeNdteLEoTiQqtP n5NA==
MIME-Version: 1.0
X-Received: by 10.170.185.133 with SMTP id b127mr64000250yke.28.1426787754960; Thu, 19 Mar 2015 10:55:54 -0700 (PDT)
Received: by 10.170.58.201 with HTTP; Thu, 19 Mar 2015 10:55:54 -0700 (PDT)
Received: by 10.170.58.201 with HTTP; Thu, 19 Mar 2015 10:55:54 -0700 (PDT)
In-Reply-To: <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> <20150319174001.GA3690@LK-Perkele-VII>
Date: Thu, 19 Mar 2015 10:55:54 -0700
Message-ID: <CACsn0cm-8jyZHDa11ya5nRBAYXZc9EF354eAyZu3ND0usVTrsg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Content-Type: multipart/alternative; boundary=001a1139d34a4def4a0511a7e9f5
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/LN28c6Qx5aRVh7dNFXNlQiTIpRc>
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 17:55:58 -0000

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.

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