IETF Logo Mail Archive

Re: [TLS] Data volume limits

Brian Smith <brian@briansmith.org> Tue, 29 December 2015 19:10 UTC

Return-Path: <brian@briansmith.org>
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 7F06D1A702C for <tls@ietfa.amsl.com>; Tue, 29 Dec 2015 11:10:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 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, 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 MjX0vI5x-ZYa for <tls@ietfa.amsl.com>; Tue, 29 Dec 2015 11:10:26 -0800 (PST)
Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (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 11C641A21B4 for <tls@ietf.org>; Tue, 29 Dec 2015 11:10:26 -0800 (PST)
Received: by mail-ob0-x235.google.com with SMTP id ba1so164828880obb.3 for <tls@ietf.org>; Tue, 29 Dec 2015 11:10:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f3CT0Blxkz89kciKkN5d9672AeiR0qKXYBShJZ82E8g=; b=S5t5GfodjqFVK7FSdymOQEvWNGdGi3fsoY7zpZ/GK4OoeFlauHlrI0h5QvOO5HhztC VNggPxpQuuc0DrmmHzPq8hyavv1BjHDGej5HHXzKUY8K7mZneqMfnuwZj10cIlOyttaK c6QLahv9PHmSaQn0vLLYJUT+SVIlPge2FeGBeTmSGO3VbdF251QZlpgQ7mZRaWs2MTFU bHWfx/zX3MhAkCL3WQZwGSEWejWrWHK2XyS5KD4L2/lWBDsiowr+MdosJva8hi+w9iFU v8aEhcrRBHPhmfRmg9Bzvhz0Z7hk0w4YGAZvzMQQBXbEFwux+XskPJ0F+Ahxbfea0PB3 GWiw==
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:date :message-id:subject:from:to:cc:content-type; bh=f3CT0Blxkz89kciKkN5d9672AeiR0qKXYBShJZ82E8g=; b=kTRnwMCJzC0h8c0pgRp7+YHLzjl3Z6xbEH1i7gvh65CBsRvHrymT6UN8t48cNOdpnG LFsKzfALrzIXAwfzL5Jl2GjzeG4+/uiqskW4fPIIcOH2uBnL8B4Bw0vsahOupzMJ1B01 0VurSouVlbY2q0QpgIt3MgksXqnbpgx5pR/6wxbHobBQFShS2+FVlFtBaetF4pODIr5i 7DBSfbDWMDizMakATUJbuy9J+sTpog0kUqSov8mCCaUdTuwNZWXf/N4ZMBIrvFAc1bYB u/glwr2JJ9guloTwMwWxom4xlk+kbShpqDg9/KgYZ+JdyjztcdAVvdNL3rVyJrkmSAYy u73Q==
X-Gm-Message-State: ALoCoQmP3eneH9kaC3JYhlh67o3/DHPlarMXsQAf3wNKUmH64aqrocJCHuSlrBiAbRZFzD4HKiyR2EQOKYAIzVYj4S2rmPofXA==
MIME-Version: 1.0
X-Received: by 10.60.134.202 with SMTP id pm10mr8333764oeb.50.1451416225507; Tue, 29 Dec 2015 11:10:25 -0800 (PST)
Received: by 10.76.62.8 with HTTP; Tue, 29 Dec 2015 11:10:25 -0800 (PST)
In-Reply-To: <20151228205610.GA5798@LK-Perkele-V2.elisa-laajakaista.fi>
References: <20151228205101.17780804.92503.42669@ll.mit.edu> <20151228205610.GA5798@LK-Perkele-V2.elisa-laajakaista.fi>
Date: Tue, 29 Dec 2015 09:10:25 -1000
Message-ID: <CAFewVt4rTNqXwOFp7PhvNTdiG7SdyjW1_wATdXOeQv7-uRcdTQ@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary="047d7b417a638b241d05280e2c2b"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/NQAs9rQ1d6U2v_Efr9v4ydpVPco>
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:10:27 -0000

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 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.

[1] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133.pdf
.

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

v2.23.0 | Report a Bug | By Email