IETF Logo Mail Archive

Re: [TLS] Data volume limits

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Wed, 30 December 2015 00:20 UTC

Return-Path: <prvs=080653b4e8=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 508441A8F35 for <tls@ietfa.amsl.com>; Tue, 29 Dec 2015 16:20:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.208
X-Spam-Level:
X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FW7rPBsuIWmE for <tls@ietfa.amsl.com>; Tue, 29 Dec 2015 16:20:39 -0800 (PST)
Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2767D1A8F33 for <tls@ietf.org>; Tue, 29 Dec 2015 16:20:38 -0800 (PST)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id tBU0K18X000831; Tue, 29 Dec 2015 19:20:37 -0500
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Eric Rescorla <ekr@rtfm.com>, Dave Garrett <davemgarrett@gmail.com>
Thread-Topic: [TLS] Data volume limits
Thread-Index: AdFCl+LEde9nh48KlkmRxpLGJ4HFmw==
Date: Wed, 30 Dec 2015 00:20:28 +0000
Message-ID: <20151230002037.17780804.91976.42860@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="===============0965585041=="
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-30_01:2015-12-29,2015-12-29,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-1512300003
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/qBm76IBlDs6NXuuA-Jn8_YZIVwc>
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: Wed, 30 Dec 2015 00:20:41 -0000

I like option (2) from Eric's taxonomy.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
From: Eric Rescorla
Sent: Tuesday, December 29, 2015 18:12
To: Dave Garrett
Cc: Florian Weimer; tls@ietf.org
Subject: Re: [TLS] Data volume limits



On Tue, Dec 29, 2015 at 5:08 PM, Dave Garrett <davemgarrett@gmail.com> wrote:
On Tuesday, December 29, 2015 02:10:25 pm Brian Smith wrote:
> 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
‎
The current spec mostly uses the former, so yes, I guess we really should stop saying "rekey" if this has been defined like this. The single use of "rekey" in the doc should probably be changed to "key update" if we keep things as-is, then.

Maybe. I don't find this taxonomy particularly evocative.

 
On Tuesday, December 29, 2015 02:33:38 pm Eric Rescorla wrote:
> 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.

Yes, but they are derived from the same entropy as the old keys.

Yes. I didn't say otherwise.

 
Yes, that's not the same thing, but they're not totally independent new keys either. If we're only doing this as a hack to fix ciphers that have problems (that really should just be fixed instead), then this is fine. I think it's just the fact that we _could_ add a full rekey mechanism without a fantastic amount of additional effort is what's giving some people pause.

Well, i don't know what "fantastic" means here, but we did look at this prior
to designing the present mechanism and it was a nontrivial amount of
additional complexity.

-Ekr

‎

v2.23.0 | Report a Bug | By Email