Re: [TLS] Consensus call on Implicit IV for AEAD

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Fri, 17 April 2015 12:47 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 907291B2BEC for <tls@ietfa.amsl.com>; Fri, 17 Apr 2015 05:47:46 -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 YzAKg-0rqMmh for <tls@ietfa.amsl.com>; Fri, 17 Apr 2015 05:47:43 -0700 (PDT)
Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C197D1B2BE7 for <tls@ietf.org>; Fri, 17 Apr 2015 05:47:42 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 068C5412F; Fri, 17 Apr 2015 15:47:40 +0300 (EEST)
Date: Fri, 17 Apr 2015 15:47:39 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Joseph Salowey <joe@salowey.net>
Message-ID: <20150417124739.GA30086@LK-Perkele-VII>
References: <CAOgPGoCW-znnh5VFobCFjZafxEOcwsaHZ_eByTwpCpmqfgX=6Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAOgPGoCW-znnh5VFobCFjZafxEOcwsaHZ_eByTwpCpmqfgX=6Q@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/zQnsafhtyFmqeFkWZqU06h5yfwA>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Consensus call on Implicit IV for AEAD
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: Fri, 17 Apr 2015 12:47:46 -0000

On Fri, Apr 03, 2015 at 01:34:15PM -0700, Joseph Salowey wrote:
> In the interim meeting we had consensus to use an implicit IV for AEAD.
> The proposal was to use the record sequence number and pad with zeros as
> described in pull request 155 (
> https://github.com/tlswg/tls13-spec/pull/155/files).  This was also
> discussed in the IETF-92 meeting in Dallas along with options to change the
> offset.  The consensus was to stay with the original proposal.  We are
> posting to the mailing list to confirm this consensus.

I really do not like padding with zeroes, since it would weaken
encryption relative to TLS v1.2. And this is not just if the
symmetric encryption is already broken, but applies to all[1].

This is especially prominent with AES-128[2]. And "Just use AES-256"
does not solve the issue, since it will probably not be available
in important environments[3].

None of TLS v1.2, IPSec nor SSH use AES-GCM this way, all have
secret[4] fixed nonce-parts (SSH does use Chacha20 without per-
connection nonce[5]).


OTOH, the explicit per-record nonce field for AES-GCM seems really
unnecressary. Everybody uses it sequentially anyway, so it just
wastes 8 bytes per record.



[1] If the algorithm is broken, if the zeroes or even just known
nonce further help breaking depends on type of attack (but of
course, one rather not use such broken algorithms).[6]

[2] Substantial weakening happens far before collisions become
likely. So much less than AGL's "2^60" mentioned in the meeting.

[3] And I suppose nobody really likes AES-192 (despite the fact
that seemingly just about every CPU with "AES acceleration" is able
to accelerate that too). :->

[4] Secret meaning those are derived from the main key block.

[5] The encrypted stream looks like random noise, which makes it
harder to tell where packet boundaries are (and Chacha20 is
256-bit keys anyway).

[6] SSLv3 had known nonces for EXPORT ciphers, but secret ones
for strong ones. Hmm...



-Ilari