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

Brian Smith <brian@briansmith.org> Fri, 17 April 2015 21:30 UTC

Return-Path: <brian@briansmith.org>
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 D1AF91B2CE0 for <tls@ietfa.amsl.com>; Fri, 17 Apr 2015 14:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 JNfG2m3vqRb5 for <tls@ietfa.amsl.com>; Fri, 17 Apr 2015 14:30:32 -0700 (PDT)
Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) (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 DDE751B304C for <tls@ietf.org>; Fri, 17 Apr 2015 14:30:31 -0700 (PDT)
Received: by obbfy7 with SMTP id fy7so78920257obb.2 for <tls@ietf.org>; Fri, 17 Apr 2015 14:30:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NP66597PJv3Qcj8F6oZPfKFY4o7ftg1fz4MHqif4nms=; b=Lr9IhOE/0HcC55slwGUZ2tpTticm/HewGXxS6tnk3o9xIK9A7ut2/LONf6TyqWYj1i bJFjX3TP6xJjeu9bTNuXeQYGkvSFp4LL1Nkew5XkApz78fNZfiY50lQHpalQH/gwAnco psW9DbS858yrBnpHjt7eDNTe0BOT5BVgjF4DWDgACqcCczcME6xuuwYsX5AGLFIR9HaX lz1sxz6VsdbleH7R+6+/32/62uqrupcgDaL88s1/nYNkhECUXtNdtIPhdDKSVHl+f11O LvgvuHfI/hYQwW8UsPy4Pl9oY84BSbfOqrEnLpFdOaZvV9KuvCAsq2vyhjRWS/iLEHxH JBEw==
X-Gm-Message-State: ALoCoQnaosDQsmJTWjkyEMqGH3vZUtRXyESfyxY9EMZhgu7vkDFYOnZUzqIckbiIstseuj38Rxi9
MIME-Version: 1.0
X-Received: by 10.60.139.1 with SMTP id qu1mr4771180oeb.83.1429306231367; Fri, 17 Apr 2015 14:30:31 -0700 (PDT)
Received: by 10.76.20.146 with HTTP; Fri, 17 Apr 2015 14:30:31 -0700 (PDT)
In-Reply-To: <B131C415-9282-4A27-8370-B6499B2CE415@shiftleft.org>
References: <CAOgPGoCW-znnh5VFobCFjZafxEOcwsaHZ_eByTwpCpmqfgX=6Q@mail.gmail.com> <20150417124739.GA30086@LK-Perkele-VII> <B131C415-9282-4A27-8370-B6499B2CE415@shiftleft.org>
Date: Fri, 17 Apr 2015 11:30:31 -1000
Message-ID: <CAFewVt6+rt91Q2BQX7C+dKCJSoiwgcZkwQny23gSqm8HezZi-g@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Michael Hamburg <mike@shiftleft.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/4CDJTsn5G_bKtd2oAvAEhIIcpqk>
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 21:30:34 -0000

Michael Hamburg <mike@shiftleft.org> wrote:
>> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
>> [2] Substantial weakening happens far before collisions become
>> likely. So much less than AGL's "2^60" mentioned in the meeting.
>
> Really?  Can you provide a citation?  Because if I’m reading it correctly, this is a claim that AES-128 is not a secure PRP, with significantly less than 2^60 known/chosen plaintexts, keys and compute time.

It is a claim that AES-128-*GCM* *may* (emphasis on *GCM* and *may*)
not be a perfectly secure PRP, and/or that the key agreement scheme to
be used in TLS 1.3 *may* not not be perfect. I think those are
reasonable things to doubt, absent a proof to the contrary.

>> [4] Secret meaning those are derived from the main key block.
>
> … and this is a claim that adding an extra key, which is in the nonce instead of an actual key to the cipher, makes it more secure.
>
> All this said, I agree that it’s wise to reduce the amount of cribtext you give an attacker, so long as it doesn’t cost too much complexity.  If we are really providing a fatal amount of cribtext, then we need to fix that, but then again, we should probably toss the cipher out at that point.

The argument I was making is that (a) it seems unreasonable to assume
AES-128-GCM is perfect and that they key agreement scheme is perfect,
and (b) the cost of randomizing the starting point of the nonce
counter is so low that it is worthwhile to do it just in case.

I recently read the FIPS 140-2 implementer's guidance at [1]. I think
it is worthwhile for people discussing this to read what it has to say
about AES-GCM nonce handling, which starts on page 138. It recommends
an even more stringent handling of nonces for AES-GCM, summarizing the
approach proposed for TLS 1.3 as follows:

    It may be tempting to avoid meeting the IV generation
    requirements stated in this IG if it could be guaranteed
    that any key was used only once thus avoiding the (key, IV)
    collisions regardless of the method used to generate the
    IVs. The problem with this approach is that within the
    scope of the CMVP validation neither the module itself
    nor its Security Policy can enforce the single-use-key
    condition. The risk of introducing the identical (key, IV)
    pairs outweighs the possible benefits of relaxing the IV
    generation rules."

Where the "IV generation rules" are paraphrasing, "do it the way TLS
1.2 does, or else ensure every peer uses a unique identifier as a
prefix on nonces it uses for encryption."

No matter what we do, we should address this concern in the security
considerations of the TLS 1.3 spec by stating the assumptions we are
making and guarantees we are providing regarding (key, IV) uniqueness.

Cheers,
Brian

[1] http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf