Re: [TLS] Issue 555: Generate IVs in one HKDF invocation?

Brian Smith <brian@briansmith.org> Wed, 17 August 2016 23:08 UTC

MIME-Version: 1.0
In-Reply-To: <CABcZeBMCoEhsDTTioQVCRP=qYLnijS+8wtGFLw1kyYy+fkfyhQ@mail.gmail.com>
References: <CABcZeBMCoEhsDTTioQVCRP=qYLnijS+8wtGFLw1kyYy+fkfyhQ@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
Date: Wed, 17 Aug 2016 13:08:41 -1000
Message-ID: <CAFewVt65iD1P+Zf9_BK9k2pKG8fNPjsa3JJkqzpjWhWfNSzBGg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/41pg4Lhwqn07YuOYTUBumsVUKv0>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Issue 555: Generate IVs in one HKDF invocation?
Precedence: list

Eric Rescorla <ekr@rtfm.com> 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.

Cheers,
Brian
-- 
https://briansmith.org/

Re: [TLS] Issue 555: Generate IVs in one HKDF inv… Ilari Liusvaara
Re: [TLS] Issue 555: Generate IVs in one HKDF inv… Eric Rescorla
Re: [TLS] Issue 555: Generate IVs in one HKDF inv… Brian Smith
Re: [TLS] Issue 555: Generate IVs in one HKDF inv… David Benjamin
[TLS] Issue 555: Generate IVs in one HKDF invocat… Eric Rescorla