Re: [TLS] Consensus for AEAD IV

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Sun, 26 April 2015 18:20 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 CD1E31B2C07 for <tls@ietfa.amsl.com>; Sun, 26 Apr 2015 11:20:30 -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 r_PTLUBvf4y6 for <tls@ietfa.amsl.com>; Sun, 26 Apr 2015 11:20:29 -0700 (PDT)
Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D83421B2C09 for <tls@ietf.org>; Sun, 26 Apr 2015 11:20:28 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 4D6D9817E2; Sun, 26 Apr 2015 21:20:26 +0300 (EEST)
Date: Sun, 26 Apr 2015 21:20:25 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Michael StJohns <msj@nthpermutation.com>
Message-ID: <20150426182025.GA3549@LK-Perkele-VII>
References: <CAOgPGoC14uhjrZAQvDHFQrJoyoVNELpNNd4+Hh==zwf9ipyY5g@mail.gmail.com> <CABkgnnU50pvH+LFsN3BL9LfvYhZOxmJV1JYzODeC=-JpZSh8Lw@mail.gmail.com> <CAOgPGoDNuhmnNpZ7ELCfBHS4rKuj+3j1+YiuxLkST+z1J+tOKQ@mail.gmail.com> <553C59B2.6050000@nthpermutation.com> <7E7D3069-2021-4691-AEA6-70DD1AB4476C@gmail.com> <553D27D0.7040209@nthpermutation.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <553D27D0.7040209@nthpermutation.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/7ots_sVnfbLpA36oKb5UPjOquqE>
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." <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: Sun, 26 Apr 2015 18:20:30 -0000

On Sun, Apr 26, 2015 at 02:00:48PM -0400, Michael StJohns wrote:
> On 4/25/2015 11:47 PM, Yoav Nir wrote:
> >
> >>On Apr 26, 2015, at 6:21 AM, Michael StJohns <msj@nthpermutation.com
> >><mailto:msj@nthpermutation.com>> wrote:
> 
> You're actually going to make it impossible to use TLS1.3 with generic
> hardware modules.

Define "generic hardware module".
 
What key derivation operations it supports? Both secret->secret and
secret->public (and yes, the latter _will_ be needed).

> >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.
> 
> There is no reason to treat the 96 bit quantity as secret and no one else
> does.

Oh, except SSH. The session nonce is 96 bits and secret.

(To lesser extent, IPSEC, there the session nonce is 32 bits and secret).

> TLS should use generic interfaces rather than inventing stuff that can't.

Well, given that one needs to derive public data out of secret keys, that
sure can also derive per-connection IVs out of secrets.


-Ilari