Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB4912D151 for ; Wed, 17 Aug 2016 16:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 5kJDwdW9QEzc for ; Wed, 17 Aug 2016 16:48:29 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (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 3128412D0B2 for ; Wed, 17 Aug 2016 16:48:29 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id d10so960710ybi.1 for ; Wed, 17 Aug 2016 16:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hq+pAP3Ob+qwcDE3uUyhh+8k+QOkVpPN4/RefMyuFmg=; b=vVp2dinfjV8rwiUQ4+/npqDljvl6otf4xNO3+OAkMwCmxS4CvuA8ZmlcGqNhGdMPXm lmhXJWXC1kfS/zg4TiEzsgtY36OXTZPdAGSTVxHx81CHaJEtxLd8JEWb32QJJu+FYc1g PBzqRgFGZiHdpH7/tV8QqTTxqI9ktrTN44blDSfu4FU7W4GBIwRdNB+VvPwJUoESgaIo gEFsomX5bkpc4A7LzG93mwbZaSKRSwn/wEc86xzXnV6FgIo+MPXErGs9nkEOW3wEZdqG MDCiCLogVTDMmcTwy5Xi/jZqv7E96aJEI4/2dpPvrHefb5Qvkvn42ftU42tPqneIrBSn Exog== 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:from:date :message-id:subject:to:cc; bh=hq+pAP3Ob+qwcDE3uUyhh+8k+QOkVpPN4/RefMyuFmg=; b=Mvt0IYXJOvI8GsdB4OAUa+Di/6qiRQZuN/SXynHAOVH4PCvXjpmi7YWI9cVm9BkVSe SjvD3VFywkuCt4wMlWx1CixDoKKtO8HQwSeaCGJCTRHgQQ7j0ePguQRa/oaShQq25HnV 5tYyh2UAslycf44iQlmYhMAoXWAb9qlQQqCxs9gYgtldwGUiJq552p2QUzLeC1sh6BjL u/6nbMNjI5S3/sMAyMgrXqp6wiPGvgPbhdtx+T37Bui4mCMMoYZZJa8qUkEtT151QX/5 cnmuQ9RUmS7Qz5n216xuUzf9x7ZpAIur59nxGwOF9+TkGHfqfgAUU2sNudjYqZz0Q2JS 1ONQ== X-Gm-Message-State: AEkoouuy2qV7NwiUUrFhDESR5sWm5EM8PL60q27mmH8ufvcYSqXyMcGyvJkcz7NogWf8vxPgrK+/DWTwPa2lhQ== X-Received: by 10.37.160.99 with SMTP id x90mr30115858ybh.130.1471477708498; Wed, 17 Aug 2016 16:48:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Wed, 17 Aug 2016 16:47:48 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 17 Aug 2016 16:47:48 -0700 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=94eb2c19831e1c56f3053a4d1a5a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Issue 555: Generate IVs in one HKDF invocation? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 17 Aug 2016 23:48:31 -0000 --94eb2c19831e1c56f3053a4d1a5a Content-Type: text/plain; charset=UTF-8 On Wed, Aug 17, 2016 at 4:08 PM, Brian Smith wrote: > Eric Rescorla wrote: > > Issue: > > https://github.com/tlswg/tls13-spec/issues/555 > > > > ADL suggested that we could slightly reduce the number of HKDF > > computations by generating the IVs as a single block rather than > > with individual HKDF-Expands. You can't generally do this kind > > of slice-and-dice and preserve the key boundary, but IVs are > > public anyway. > > When you say "IV," what are you referring to? Definitely the original > intent of my proposal to use client_write_iv and server_write_iv is > that they would remain secret. I suspect that some analysis might be > simplified by assuming that they are publicly-known as a worst-case > scenerio, but that's different than them being "public", and we should > design things assuming that we're trying to keep them private. > Sorry, that's bad writing on my part. I meant they should be kept private but that in practice, PKCS#11 and similar implementations almost certainly don't have support for TLS 1.3-style AES-GCM and therefore you'll have to let the IV out of the tamper boundary at least for the foreseeable future. -Ekr > > Cheers, > Brian > -- > https://briansmith.org/ > --94eb2c19831e1c56f3053a4d1a5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 17, 2016 at 4:08 PM, Brian Smith <brian@briansmith.org<= /a>> wrote:
Er= ic Rescorla <ekr@rtfm.com> wrote:=
> Issue:
>=C2=A0 =C2=A0https://github.com/tlswg/tls13-s= pec/issues/555
>
> ADL suggested that we could slightly reduce the number of HKDF
> computations by generating the IVs as a single block rather than
> with individual HKDF-Expands. You can't generally do this kind
> of slice-and-dice and preserve the key boundary, but IVs are
> public anyway.

When you say "IV," what are you referring to? Definitely t= he original
intent of my proposal to use client_write_iv and server_write_iv is
that they would remain secret. I suspect that some analysis might be
simplified by assuming that they are publicly-known as a worst-case
scenerio, but that's different than them being "public", and = we should
design things assuming that we're trying to keep them private.

Sorry, that's bad writing on my part. I mea= nt they should be kept private but
that in practice, PKCS#11 and = similar implementations almost certainly don't
have support f= or TLS 1.3-style AES-GCM and therefore you'll have to let
the= IV out of the tamper boundary at least for the foreseeable future.

-Ekr
=C2=A0

Cheers,
Brian
--
ht= tps://briansmith.org/

--94eb2c19831e1c56f3053a4d1a5a--