IETF Logo Mail Archive

Re: [TLS] Data volume limits

Eric Rescorla <ekr@rtfm.com> Mon, 28 December 2015 20:47 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 090101ACC8C for <tls@ietfa.amsl.com>; Mon, 28 Dec 2015 12:47:51 -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 7sKwrQkxPru1 for <tls@ietfa.amsl.com>; Mon, 28 Dec 2015 12:47:50 -0800 (PST)
Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (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 D0E371AC444 for <tls@ietf.org>; Mon, 28 Dec 2015 12:47:49 -0800 (PST)
Received: by mail-yk0-x22e.google.com with SMTP id k129so91029497yke.0 for <tls@ietf.org>; Mon, 28 Dec 2015 12:47:49 -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=lryks1V/ARxZftMBQAf5QM4Oz43UZpBQOV0ge4L0LLs=; b=xbPkdZ/Xu5ItIleb/3eqV852DPVRdam8LbVibndz9CWjhF38uBI/rs5X/VIkTx2145 B9ARTVOdU3RJcsOTCbXzCn3yl8QkDDgSk2qjwASzXJWieyC9aFzR7qxrq/GG0RmeUosi GgTkUrjxSqGkInjM44m7GYY71Nhc6FL7k31+jmnDrpNR3MvQYT23xkJgK/0qf8NXQVvR /WBlkaqZd60WxZMxhCJkdXfGrWLbOtmHqQ9W3CPRkvm5lalNInPrRzYuvcbIPYPcMSbd IznoM33ycHMyFDs/5a8V7/WE7+EuNzdNcpLMrbuq1OnArpwQcejbB67Znb9W1vaBwsCM DQ9Q==
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=lryks1V/ARxZftMBQAf5QM4Oz43UZpBQOV0ge4L0LLs=; b=flsr/0CiybaR8MeYelv3pjZZakr8PaZjRtACBceniCNEcfRsFda1LNQ5+lRMWqNmZF xEVU5V1QWE3AChRFU9wlnWbPvjk2AuBD8SQEqr3NQBjxyEtTkDw6By6e6TYGJPF9S1Pt 4eiCtEYMIsUZZNr0ZowZk0D6PongcwzycuwIv/PWvQtGhJz5hxCKd/9eK6KkMCgSXWcY LLrBblH+D8ondiZk1ae4cZ6fOD02OG9ktSowUwbM4spD7pTYRqRvokMXNjnymbqDcDIa yE0hl+vV77Z3jKwepLhiNWuwCcvyRgWTmQ/TrEHnq5INtN890D8zVKKS21syO12Xu8XW a7bA==
X-Gm-Message-State: ALoCoQnWJCk2xfWcP0/j+qrk2ZFAcBRxrMJxgf0YknHzSEGzG9ohaLrR1zTZZUxkPhVTy/TSVvQ4RhrdXONENd9rsvN2W51aHQ==
X-Received: by 10.129.153.3 with SMTP id q3mr47371634ywg.231.1451335668983; Mon, 28 Dec 2015 12:47:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.249.197 with HTTP; Mon, 28 Dec 2015 12:47:09 -0800 (PST)
In-Reply-To: <20151228204103.17780804.52985.42662@ll.mit.edu>
References: <20151228204103.17780804.52985.42662@ll.mit.edu>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 28 Dec 2015 15:47:09 -0500
Message-ID: <CABcZeBPf3AW4qWMw+eYgTOsifPUirAeONZ2BtTcyZk7wX+BDZw@mail.gmail.com>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
Content-Type: multipart/alternative; boundary="94eb2c0bbfae0014100527fb6baa"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/p5JWxPraty2m5FXelMjZycdAKAE>
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: Mon, 28 Dec 2015 20:47:51 -0000

To be clear, the concern that we are trying to alleviate is encrypting too
much plaintext with the
same key (see the discussion by Watson at the beginning of this thread).
For that purpose,
I'm not following why we need to introduce new randomness (draft-11 doesn't
do so,
but just cranks the KDF forward).

It's possible I've misunderstood something, though, so happy to be
corrected.

-Ekr



On Mon, Dec 28, 2015 at 3:40 PM, Blumenthal, Uri - 0553 - MITLL <
uri@ll.mit.edu> wrote:

> Off-hand, key update or re-key without new/fresh‎ randomness sounds weird.
>
>
> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
> *From: *Eric Rescorla
> *Sent: *Monday, December 28, 2015 15:37
> *To: *Florian Weimer
> *Cc: *tls@ietf.org
> *Subject: *Re: [TLS] Data volume limits
>
>
>
> On Mon, Dec 28, 2015 at 3:33 PM, Florian Weimer <fweimer@redhat.com>
> wrote:
>
>> On 12/28/2015 09:11 PM, Eric Rescorla wrote:
>>
>> >> You still have the added complexity that during rekey, you need to
>> >> temporarily switch from mere sending or receiving to at least
>> >> half-duplex interaction.
>> >>
>> >
>> > That's not intended. Indeed, you need to be able to handle the old key
>> > in order to send/receive the KeyUpdate. Can you elaborate on your
>> concern?
>>
>> Ah, so you want to keep the current mechanism and not inject fresh
>> randomness?  Isn't this fairly risky?
>
>
> Can you explain the risk you are concerned about in more detail?
>
> -Ekr
>
>
>
>

v2.23.0 | Report a Bug | By Email