Re: [TLS] Data volume limits

Eric Rescorla <ekr@rtfm.com> Tue, 29 December 2015 19:34 UTC

Return-Path: <ekr@rtfm.com>
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 284E21A88EF for <tls@ietfa.amsl.com>; Tue, 29 Dec 2015 11:34:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 rXrZWo-zheG3 for <tls@ietfa.amsl.com>; Tue, 29 Dec 2015 11:34:19 -0800 (PST)
Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (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 D85A41A88ED for <tls@ietf.org>; Tue, 29 Dec 2015 11:34:18 -0800 (PST)
Received: by mail-yk0-x232.google.com with SMTP id a85so60555772ykb.1 for <tls@ietf.org>; Tue, 29 Dec 2015 11:34:18 -0800 (PST)
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:content-type; bh=R9aLyG2i85D2+q2LyosUZtvH+sKlo+Unl9At6CipBtE=; b=oRBuoFKUQltHBgVCL6XFoDPZwI8Y1E5DGQfLcWOJcsGKHR+F2tLPPX8Pc4Wd5f0Bmy d9Gfoqkv9ng4sceo+OTL5SadfnPjA9WFNyUuPU/fPqbWUBdOOAxUqbjS6hTaZ12UXA38 PixCgUftBjrNppApJdncw+Ozk0iXYJwk8UF7FHBzcxwyZeK9CraAx8JqxhBdAaRbMbK1 7PDQNsSBXjy10JtfOpytQZEd7PGFeLHWhWiiuuzEluc5u8ExiWZPjQ9OqiVgMfO8S8Xp KD2c/NVXnxWE/e7x6wfpmK0vtQzIYUvJeR4Bvm/D3XsvWfFJAyjZiEq/XWuGBT3oLnDw IJAA==
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:content-type; bh=R9aLyG2i85D2+q2LyosUZtvH+sKlo+Unl9At6CipBtE=; b=bsAaid3KKLtmbzEgmZQQEeTtH9C5gkfFAtiThYF1oPY8wPhe8N/bP8Kj5c5J5BrNla 3X08isxo0dy8eWQoKuueCsBVUfkkJFPXagOR2ZO+shPA0uhEwI8EddquUi2vgZjMwSrQ feqj/hnHk/uCd1ZMCfAgAzCIvkcBfMQYLn+XgJHxXMW6wmZhE5rm6X4uvhe0+w1pX3Ho bK5pMG1vG/zsCT1PwhXbBVCcm71ZqGst9Rz3rLUYMF8K4FF/24vl3Z+RSZTA+Wi/wml+ buSavQAyQUHZFt4164lO4nbPU+0pDv6CbM+Dwm+1MLPP0t3c0QXAx7pYnhZ9DX+I0hi+ +HoA==
X-Gm-Message-State: ALoCoQnRHy8ZLg8N/LD6BcZzjWeb/jjy9ZcVySjXLZ3elPrWN0dzCnVjO+nyZi2UsJJBaOnbvBrt1rM+HDi+NQ7cGO/Wi63WKQ==
X-Received: by 10.129.46.208 with SMTP id u199mr44906010ywu.129.1451417658073; Tue, 29 Dec 2015 11:34:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.249.197 with HTTP; Tue, 29 Dec 2015 11:33:38 -0800 (PST)
In-Reply-To: <CAFewVt4rTNqXwOFp7PhvNTdiG7SdyjW1_wATdXOeQv7-uRcdTQ@mail.gmail.com>
References: <20151228205101.17780804.92503.42669@ll.mit.edu> <20151228205610.GA5798@LK-Perkele-V2.elisa-laajakaista.fi> <CAFewVt4rTNqXwOFp7PhvNTdiG7SdyjW1_wATdXOeQv7-uRcdTQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 29 Dec 2015 14:33:38 -0500
Message-ID: <CABcZeBMr9h=rB-8ztK3TV=fYQDzjcCxMzG8M4JibV7O0_MFjfg@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: multipart/alternative; boundary=001a11408592ee564e05280e8110
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/6RllNpbkA4orUDYJfosnm5aZIyI>
Cc: Florian Weimer <fweimer@redhat.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Data volume limits
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 29 Dec 2015 19:34:20 -0000

On Tue, Dec 29, 2015 at 2:10 PM, Brian Smith <brian@briansmith.org> wrote:

> Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
>
>> OTOH, you can't drop an attacker knowing older key without doing
>> new key exchange.
>>
>
> I think it would be very unfortunate to have the complexity of key update
> (the new keys are derived from the old keys) without having the benefits of
> rekeying (the new keys are independent of the old keys).
>

Note: the keys here are *not* derived from the old keys. Rather, they are
derived via
a KDF from the same secret that was used to generate the old keys. I.e.,

  K_send_0 = KDF(MK_0, <label1>)
  K_recv_0 = KDF(MK_0, <label2>)
  MK_1 = KDF(MK_0, <label3>)
  K_send_1 = KDF(MK_1, <label1>)
  K_recv_1 = KDF(MK_1, <label2>)



Note that NIST Special Publication 800-133 [1] defines these separate
> terms, and I suggest we use them in this conversation to avoid confusion:
>
> Key update: A procedure in which a new cryptographic key is computed as a
> function of the (old) cryptographic key that it will replace.
>
> Rekey: A procedure in which a new cryptographic key is generated in a
> manner that is independent of the (old) cryptographic key that it will
> replace.
>

Hmm... It seems to me that there are three (at least) three separate
possible designs:

1. Generate the new keys by a new application of the KDF with no additional
inputs.
2. Generate the new keys by a new application of the KDF with additional
random inputs.
3. Generate the new keys by a new PK key exchange (potentially also using
the old
    keys and new random inputs).

These all have different security properties and it's not clear to me which
buckets
these fall into.

As far as complexity goes, 3 is more complicated than 2 which is more
complicated than 1.

-Ekr