Return-Path: 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 DC48D1B34F4 for ; Sat, 25 Apr 2015 20:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 5C__m8e0ie5A for ; Sat, 25 Apr 2015 20:47:14 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (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 B34291B34F3 for ; Sat, 25 Apr 2015 20:47:13 -0700 (PDT) Received: by wiun10 with SMTP id n10so56950578wiu.1 for ; Sat, 25 Apr 2015 20:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=PntXWEyrkfCdixlfyuXpaJf3wleVhzrr4A6fGGCZY/A=; b=ziWFz/jiVORU8TN7ndIws2ktGn++w8/5AwuGtWYIR/kTD3O3qBMFPdNatCKVuVuEuZ P4dslaXlNqsy0044Ga8BLsM9cD1mqPyjispBChAtbGABHPlryIPej9s+WDeutQfadBVi cV+sas6PKGG6sB29O/dyyU4oCihW53jGdtojwFDPBCy2Jo/uJdgfjWxJB+AGrz4M3lNQ jaJ8slEGQCFS9uHcBCCnm1f0zyQoh7lVsK2ejjXj3UERmPyMOtsyt+8ff9KUMfQ/uttp Pi1He5rBgeDASfQO/BeoSgNhGgfCkyS6kRF1/cRBhou3geH4SDMzUAMWrLV0vspzw63W WJZA== X-Received: by 10.180.86.234 with SMTP id s10mr9439222wiz.50.1430020032523; Sat, 25 Apr 2015 20:47:12 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id dz4sm5684794wib.17.2015.04.25.20.47.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Apr 2015 20:47:11 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B6F81507-1420-4B72-A849-0BAB99F552E3" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <553C59B2.6050000@nthpermutation.com> Date: Sun, 26 Apr 2015 06:47:09 +0300 Message-Id: <7E7D3069-2021-4691-AEA6-70DD1AB4476C@gmail.com> References: <553C59B2.6050000@nthpermutation.com> To: Michael StJohns X-Mailer: Apple Mail (2.2098) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Consensus for AEAD 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 03:47:16 -0000 --Apple-Mail=_B6F81507-1420-4B72-A849-0BAB99F552E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Apr 26, 2015, at 6:21 AM, Michael StJohns = wrote: >=20 > On 4/24/2015 4:44 PM, Joseph Salowey wrote: >>=20 >>=20 >> On Fri, Apr 24, 2015 at 1:00 PM, Martin Thomson = > wrote: >> On 24 April 2015 at 10:10, Joseph Salowey > wrote: >> > The general consensus on the list seems to prefer to derive "IV" = and use it >> > to make the AEAD nonce less predictable. Most folks seemed to be OK = with >> > this approach. In Dallas, there was significant support for = using the >> > derived "IV" as a per session XOR mask for the counter. If you = have >> > objections to this approach please respond on the list by May 1, = 2015 . >>=20 >>=20 >> You aren't being particularly precise about the process here. >>=20 >> I believe that these were the two options that were most debated: >>=20 >> a) nonce =3D zeroes(N_MIN) XOR counter >> b) nonce =3D HKDF(...., N_MIN) XOR counter >>=20 >> Did you mean the latter option? >>=20 >> [Joe] Yes, the later where the quantity XORed with the counter is = derived during the handshake. =20 >=20 > In general, APIs for hardware (and software) encryption are set up as = init, multiple updates and finalize. The arguments to init are = generally a handle pointing to the key, a selection of the encryption = mode and the initialization parameters specific to that mode. The = initialization parameters generally include material for the IV = (obviously not used in ECB), and other mode specific items. For CCM, = most implementations use the block formatting function described in = appendix A of the NIST spec and that function uses as input to the = initialization a "nonce" as well as information about the length of the = AAD. >=20 > All of the Init data is non-secret information (note that I said = handle to key, and not key above - the handle is non-secret, the key = material is secret) and must be shared implicitly or explicitly between = sender and receiver. >=20 > All of that is a long way of saying that making the nonce be some sort = of output of the HKDF is probably a bad idea as the general use for a = KDF is to produce secret key material. >=20 >=20 > A zero session nonce combined with the message sequence number to form = unique per-key value is acceptable cryptographically - at least for GCM = and CCM. (and that's really the same thing as 0 XOR counter as far as = I can tell). >=20 >=20 > A randomly generated session nonce concatenated with the message = sequence number to produce a message nonce is acceptable = cryptographically and provides no less protection than generating a long = session nonce and xor'ing the sequence number in to produce the message = nonce.=20 >=20 > AFAICT b) provides no additional security over a). The security of = CCM and GCM is NOT dependent on the secrecy of the IV/Nonce/sequence = number, only in its uniqueness for a given key, and (b) appears to be = trying to make the IV secret. >=20 > Doing (b) will make it difficult to implement TLS using generic HSM = functions as there will probably need to be some way of piping the = secret output of HKDF to be the per message IV. I don=92t see why. Make the 128- or 256-bit key one part of the keying = material, and the 96-bit quantity another part of the keying material. A = single handle references a structure containing both. Now you pass the encryption function the handle, the data to be = encrypted (and protected) and a message counter. The function (hardware = or software) converts the counter into a nonce by XOR-ing with the = quantity, and proceeds from there. There is no reason not to treat the = 96-bit quantity as anything but secret. Doesn=92t this solve you API issue? Yoav --Apple-Mail=_B6F81507-1420-4B72-A849-0BAB99F552E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Apr 26, 2015, at 6:21 AM, Michael StJohns <msj@nthpermutation.com> wrote:

=20 =20
On 4/24/2015 4:44 PM, Joseph Salowey wrote:


On Fri, Apr 24, 2015 at 1:00 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 24 April 2015 at 10:10, Joseph Salowey <joe@salowey.net> wrote:
> The general consensus on the list seems to prefer to derive "IV" and use it
> to make the AEAD nonce less predictable. Most folks seemed to be OK with
> this approach.    In Dallas, there was significant support for using the
> derived "IV" as a per session XOR mask for the counter.  If you have
> objections to this approach please respond on the list by May 1, 2015 .


You aren't being particularly precise about the process here.

I believe that these were the two options that were most debated:

a)  nonce =3D zeroes(N_MIN) XOR counter
b)  nonce =3D HKDF(...., N_MIN) XOR counter

Did you mean the latter option?

[Joe] Yes, the later where the = quantity XORed with the counter is derived during the handshake.  =

In general, APIs for hardware (and software) encryption are set up as init, multiple updates and finalize.  The arguments to init = are generally a handle pointing to the key, a selection of the encryption mode and the initialization parameters specific to that mode.  The initialization parameters generally include material = for the IV (obviously not used in ECB), and other mode specific = items.  For CCM, most implementations use the block formatting function described in appendix A of the NIST spec and that function uses as input to the initialization a "nonce" as well as information about the length of the AAD.

All of the Init data is non-secret information (note that I said handle to key, and not key above - the handle is non-secret, the key material is secret) and must be shared implicitly or explicitly between sender and receiver.

All of that is a long way of saying that making the nonce be some sort of output of the HKDF is probably a bad idea as the general use for a KDF is to produce secret key material.


A zero session nonce combined with the message sequence number to form unique per-key value is acceptable cryptographically - at least for GCM and CCM.    (and that's really the same thing = as 0 XOR counter as far as I can tell).


A randomly generated session nonce concatenated with the message sequence number to produce a message nonce is acceptable cryptographically and provides no less protection than generating a long session nonce and xor'ing the sequence number in to produce the message nonce.

AFAICT b) provides no additional security over a).   The = security of CCM and GCM is NOT dependent on the secrecy of the IV/Nonce/sequence number, only in its uniqueness for a given key, and (b) appears to be trying to make the IV secret.

Doing (b) will make it difficult to implement TLS using generic HSM functions as there will probably need to be some way of piping the secret output of HKDF to be the per message IV.

I don=92t = see why. Make the 128- or 256-bit key one part of the keying material, = and the 96-bit quantity another part of the keying material. A single = handle references a structure containing both.

Now you pass the encryption function the handle, = the data to be encrypted (and protected) and a message counter. The = function (hardware or software) converts the counter into a nonce by = XOR-ing with the quantity, and proceeds from there. There is no reason = not to treat the 96-bit quantity as anything but secret.

Doesn=92t this solve you API issue?

Yoav


= --Apple-Mail=_B6F81507-1420-4B72-A849-0BAB99F552E3--