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

Brian Smith <> Thu, 19 March 2015 19:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C489B1A8F40 for <>; Thu, 19 Mar 2015 12:53:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RN6YczmJ12Vc for <>; Thu, 19 Mar 2015 12:53:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1DCCD1A8848 for <>; Thu, 19 Mar 2015 12:53:55 -0700 (PDT)
Received: by obcxo2 with SMTP id xo2so62946840obc.0 for <>; Thu, 19 Mar 2015 12:53:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WtABsQURnUuoQ56VstGDzIg3+nVIrZtos8RF1zI6dZ0=; b=WqbfxaQ5XqXYnn9Yu4VwTHD39BTfta7I6PBMMOAL6Qt75EaEH1p4/gAWUWWywjWvkJ FnVDSszAi89huc62yek1OOUtxENeXuDTgg/MM2nnYUNL/MsDQGaWOO3gwQ06xKoq5ltM eyeKOUSHqh2pbO9LbHsbiQ4mYXsGXD8j2AiaVpw0EmBlRaUe6czUZCk6jm7JVxXMK0MP RjsabFjz3JggM6Vt1FVPEsXHemMUHtx3/vIjUTV0/lVFyI7POvX8b+G99ik6a23eNIxL XFWNnZ+jMQn1Ho6/8M2w7OfTGjx6PvaPEm3tGN4xPx8+VkOQn1Po/5+RYv0G+bAM7zIr emsA==
X-Gm-Message-State: ALoCoQnKAxpjtCYgN3BaNyhKOC7JlEMAYk5uKwwZtjQ6JKLonkky5J4+GYv4AAeQV4M6qvn7dMET
MIME-Version: 1.0
X-Received: by with SMTP id k1mr27832222obz.20.1426794834624; Thu, 19 Mar 2015 12:53:54 -0700 (PDT)
Received: by with HTTP; Thu, 19 Mar 2015 12:53:54 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 19 Mar 2015 09:53:54 -1000
Message-ID: <>
From: Brian Smith <>
To: Eric Rescorla <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Mar 2015 19:53:58 -0000

Eric Rescorla <> wrote:
> PR:
> Target merge date: 3/21

My concern about this is the same one already raised on the CFRG mailing list:
in response to:

In particular, massively parallel attacks on many keys at once seem
like the most promising way to break AES-128. It seems bad to have
popular endpoints encrypting the same plaintext block (e.g. "GET /
HTTP/1.1\r\n") with the same nonce (1) with different keys. That seems
like exactly the recipe for making such attacks succeed.

It seems like it would be better, instead, to require that the initial
nonces to be calculated from the keyblock established during key
agreement, and then have them incremented as counters (with
wraparound) in the same fashion as being proposed. This, combined with
the fact that the key agreement will always be using ephemeral keys,
should prevent any such massively-parallel attack from working.

Note that this is a concern more for AES-128 than it is for ChaCha20
because ChaCha20 mitigates the issue by using a 256-bit key.

Other than disagreeing with how the initial nonce is determined, I
agree that the implicit counter approach is better than the explicit
per-record nonce approach.

I think this issue should be addressed before this change is made.