Re: [TLS] HSM-friendly Key Computation

Brian Smith <> Fri, 17 April 2015 21:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1CFE91B2EB1 for <>; Fri, 17 Apr 2015 14:18:15 -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 VY4LMN2N3duo for <>; Fri, 17 Apr 2015 14:18:13 -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 5A2911ACEA7 for <>; Fri, 17 Apr 2015 14:18:13 -0700 (PDT)
Received: by obbeb7 with SMTP id eb7so80330010obb.3 for <>; Fri, 17 Apr 2015 14:18:12 -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 :content-transfer-encoding; bh=wzCrRIMJXWfpysNPSSXRvKNnwSGhob687Aq3b8O4xoI=; b=CazYTZig9t37sbInFB7bZL60zAhfxGvWjZSR4JIxuWsq9n9zO7Ht12vE4hR4V2ZGpI LSknmXMq7+Vs6J8w+zDLJ5WvkYM1KEwyj2dMUmDIb8zqu4BLK79D8H42If7888Y0zQJ8 D014imTLHNDae+bFjEUX4Vh22SJsciRcQfzXxvLZSnaa17/OzCQsTlnr/pdT/LMKPOJC L0jb3bssbSynD1WnEjxyHwDk5CeiFhYGXhkXmsx5fomaw4D3trw0yA6X6X+W0VuGucgK r6ookVzsAsG3EBoIxnbViIaZaz2HGqTU8jf1TMOr8fIow5Y0+SRC+6F/9IMecz/UMo4s Lq3w==
X-Gm-Message-State: ALoCoQkMZ7VQNJuFiQrBSoYxxf2mcPEz764xa567I1TwEK+a3vhqobzGY3JJeDum7u43E45L5UEj
MIME-Version: 1.0
X-Received: by with SMTP id j185mr4492585oig.68.1429305492674; Fri, 17 Apr 2015 14:18:12 -0700 (PDT)
Received: by with HTTP; Fri, 17 Apr 2015 14:18:12 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Fri, 17 Apr 2015 11:18:12 -1000
Message-ID: <>
From: Brian Smith <>
To: Yoav Nir <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [TLS] HSM-friendly Key Computation
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: Fri, 17 Apr 2015 21:18:15 -0000

Yoav Nir <> wrote:
>> On Apr 17, 2015, at 10:40 PM, Eric Rescorla <> wrote:
>> We should defer this issue until we know whether we are generating an IV
>> at all.
> The client_write_iv and server_write_iv are needed, and I’m not aware of any contention about them. In AES-GCM they are used for the “salt” value, and the chacha20-poly1305 draft uses the same terminology for a 32-bit fixed part of the nonce that is derived from the key buffer.
> This is not the same as the per-record IV that we *are* considering dropping.

I think you're misunderstanding what is being discussed. As far as I
know, nobody objects to using the record sequence number in a way that
turns the nonce into a counter. The only thing being debated is
whether client_write_iv and server_write_iv are used. See the actual
pull request [1]. The proposal put forth in that pull request is that
the nonce will consist *only* of the per-record sequence number,
padded with zeros, and without the part that was comprised of
client_write_iv and server_write_iv.