IETF Logo Mail Archive

Re: [TLS] Data volume limits

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Mon, 28 December 2015 20:40 UTC

Return-Path: <prvs=0804fffebe=uri@ll.mit.edu>
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 E57791AC529 for <tls@ietfa.amsl.com>; Mon, 28 Dec 2015 12:40:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.808
X-Spam-Level:
X-Spam-Status: No, score=-2.808 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham
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 w2iRL_rFU3uP for <tls@ietfa.amsl.com>; Mon, 28 Dec 2015 12:40:57 -0800 (PST)
Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id E88CD1AC44A for <tls@ietf.org>; Mon, 28 Dec 2015 12:40:56 -0800 (PST)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id tBSKet69010342; Mon, 28 Dec 2015 15:40:55 -0500
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Eric Rescorla <ekr@rtfm.com>, Florian Weimer <fweimer@redhat.com>
Thread-Topic: [TLS] Data volume limits
Thread-Index: AdFBsAxode9nh48KlkmRxpLGJ4HFmw==
Date: Mon, 28 Dec 2015 20:40:54 +0000
Message-ID: <20151228204103.17780804.52985.42662@ll.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="===============1554088141=="
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2015-12-28_13:2015-12-28,2015-12-28,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1511060000 definitions=main-1512280387
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/dJ9P9dDwF72Hv5kTSR0hLRk_CaM>
Cc: "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:40:59 -0000

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