Re: [TLS] Data Volume Limits Analysis

Hey Martin, You're right, this analysis works for any block cipher with 128 bit output that is "good enough" (a pseudorandom permutation), and so for all versions of AES regardless of the key size. Determining the appropriate key size for the block cipher relies on accounting for possible

Re: [TLS] Data Volume Limits Analysis

* aluykx [23/03/2016 09:12:02] wrote: > >Finally, and this calls for an opinion: do you believe that given these > >results > >we should include a KeyUpdate feature in TLS 1.3? > > Ideally it would be better to include a KeyUpdate feature, but the added > complexity

Re: [TLS] Data Volume Limits Analysis

Atul, Kenny, Thanks for doing this. My initial impression is that these results are uncomfortably close to the line for AES-GCM, especially for the scenario where we have multiple keys: there are probably well upward of 2^{32} HTTPS connections a day. A few questions: 1. As I understand it,

[TLS] Data Volume Limits Analysis

Kenny Paterson and I prepared a document providing an overview of how much data ChaCha20+Poly1305 and AES-GCM can process with a single key. Besides summarizing the results, the document also gives an explanation of why the limits are there. The document confirms the analysis done by Watson

Re: [TLS] Data volume limits

On 01/04/2016 12:59 PM, Hubert Kario wrote: > On Monday 28 December 2015 21:08:10 Florian Weimer wrote: >> On 12/21/2015 01:41 PM, Hubert Kario wrote: >>> if the rekey doesn't allow the application to change authentication >>> tokens (as it now stands), then rekey is much more secure than >>>

Re: [TLS] Data volume limits

On 12/28/2015 10:09 PM, Salz, Rich wrote: >> When the key is changed, the change procedure should involve new randomness. > > I don't think this is necessary, and I don't think the common crypto > expertise agrees with you, either. But I am not a cryptographer, maybe one of > the ones on this

Re: [TLS] Data volume limits

On Monday 04 January 2016 13:02:57 Florian Weimer wrote: > On 01/04/2016 12:59 PM, Hubert Kario wrote: > > On Monday 28 December 2015 21:08:10 Florian Weimer wrote: > >> On 12/21/2015 01:41 PM, Hubert Kario wrote: > >>> if the rekey doesn't allow the application to change > >>> authentication >

Re: [TLS] Data volume limits

On 01/04/2016 01:19 PM, Hubert Kario wrote: >> Dealing with this during the initial handshake is fine. But >> supporting direction-switching after that is *really* difficult. > > yes, this is a bit more problematic, especially for one-sided transfers. > For example, when one side is just

Re: [TLS] Data volume limits

> "ER" == Eric Rescorla writes: ER> In TLS, we use a distinct nonce for each record and then a block counter ER> inside the record. So, it's true that you couldn't encrypt a record that ER> was more than 2^{32} * 256 bits long, but since TLS records can't be ER> more than 16KB

Re: [TLS] Data volume limits

On Tue, Dec 29, 2015 at 2:10 PM, Brian Smith wrote: > Ilari Liusvaara 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

Re: [TLS] Data volume limits

On 01/01/2016 06:35 AM, Aaron Zauner wrote: > This might be a good time to point again to my existing AES-OCB > draft that hasn't really seen a lot of discussion nor love lately. > It expired but I've recently updated the draft (not yet uploaded > to IETF as I'm waiting for implementer feedback

Re: [TLS] Data volume limits

I think it is a good idea to rekey AES-GCM after approximately 2^32 records, give or take a few magnitudes. The question for me isn't whether AES-GCM requires frequent rekeying (it does), but exactly how much complexity the rekeying mechanism would add, to the protocol and to implementations.

Re: [TLS] Data volume limits

On Fri, Jan 01, 2016 at 01:54:00PM +0100, Henrick Wibell Hellström wrote: > I think it is a good idea to rekey AES-GCM after approximately 2^32 records, > give or take a few magnitudes. > > The question for me isn't whether AES-GCM requires frequent rekeying (it > does), but exactly how much

Re: [TLS] Data volume limits

Hi Samuel, * Samuel Neves [01/01/2016 12:19:36] wrote: > OCB is, if anything, worse than GCM when it comes to data volume limits. It > has the same confidentiality bounds as GCM > (slightly worse, in fact), but once you hit a collision you also lose > authenticity and enable

Re: [TLS] Data volume limits

[Msg for followup picked at random from this thread -JimC] One thing we should remember on this thread is that it does not only apply to aes and its' 128-bit block size. Because TLS chose to create a NotQuiteChaCha rather than use ChaCha, its chacha20poly1305 also has a small data volume limit

Re: [TLS] Data volume limits

Quoting Aaron Zauner : On the other hand, after 2^60 OCB messages of 2^16 blocks (and thus 2^76 total blocks), a block collision is almost guaranteed to have happened, enabling the aforementioned forgeries. Sure. Would you see any way to improve this situation in the draft,

Re: [TLS] Data volume limits

On Fri, Jan 1, 2016 at 11:00 AM, James Cloos wrote: > [Msg for followup picked at random from this thread -JimC] > > One thing we should remember on this thread is that it does not only > apply to aes and its' 128-bit block size. > > Because TLS chose to create a

Re: [TLS] Data volume limits

Hi, * Simon Josefsson [16/12/2015 09:44:55] wrote: > I don't like re-keying. It is usually a sign that your primitives are > too weak and you are attempting to hide that fact. To me, it is similar > to discard the first X byte of RC4 output. > > If AES-GCM cannot provide

Re: [TLS] Data volume limits

Ilari Liusvaara 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

Re: [TLS] Data volume limits

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

Re: [TLS] Data volume limits

On Tue, Dec 29, 2015 at 5:08 PM, Dave Garrett 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: > >

Re: [TLS] Data volume limits

. From: TLS <tls-boun...@ietf.org> on behalf of Dang, Quynh <quynh.d...@nist.gov> Sent: Friday, December 18, 2015 10:49 AM To: tls@ietf.org Subject: Re: [TLS] Data volume limits The collision probability of ciphertext blocks also depends

Re: [TLS] Data volume limits

553 - MITLL; Eric Rescorla Cc: Florian Weimer; tls@ietf.org Subject: RE: [TLS] Data volume limits > When the key is changed, the change procedure should involve new randomness.  ‎ I don't think this is necessary, and I don't think the common crypto expertise agrees with you, either. But I am not

Re: [TLS] Data volume limits

Rescorla Sent: Monday, December 28, 2015 15:47 To: Blumenthal, Uri - 0553 - MITLL Cc: Florian Weimer; tls@ietf.org Subject: Re: [TLS] Data volume limits 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

Re: [TLS] Data volume limits

On Mon, Dec 28, 2015 at 08:51:01PM +, Blumenthal, Uri - 0553 - MITLL wrote: > When too much plaintext has been encrypted with the same key, the > key needs to be changed. When the key is changed, the change > procedure should involve new randomness.  > > What's the confusion here??? OTOH,

Re: [TLS] Data volume limits

> When the key is changed, the change procedure should involve new randomness.  I don't think this is necessary, and I don't think the common crypto expertise agrees with you, either. But I am not a cryptographer, maybe one of the ones on this list can chime in. "Crank the KDF" suffices.

Re: [TLS] Data volume limits

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

Re: [TLS] Data volume limits

m 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 Weime

Re: [TLS] Data volume limits

On 12/21/2015 01:41 PM, Hubert Kario wrote: > if the rekey doesn't allow the application to change authentication > tokens (as it now stands), then rekey is much more secure than > renegotiation was in TLS <= 1.2 You still have the added complexity that during rekey, you need to temporarily

Re: [TLS] Data volume limits

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

Re: [TLS] Data volume limits

Scott, Henrick, Are you persuaded by Watson's analysis? Thanks, -Ekr On Mon, Dec 21, 2015 at 7:41 AM, Hubert Kario wrote: > On Tuesday 15 December 2015 20:01:58 Bill Frantz wrote: > > So we have to trade off the risks of too much data vs. the risks > > of a complex rekey

Re: [TLS] Data volume limits

On Mon, Dec 28, 2015 at 3:33 PM, Florian Weimer 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. >

Re: [TLS] Data volume limits

On Tuesday 15 December 2015 20:01:58 Bill Frantz wrote: > So we have to trade off the risks of too much data vs. the risks > of a complex rekey protocol vs. the risks having the big data > applications build new connections every 2**36 or so bytes. > > If we don't have rekeying, then the big data

Re: [TLS] Data volume limits

-* property, the above restriction is not needed. Quynh. From: TLS <tls-boun...@ietf.org> on behalf of Yoav Nir <ynir.i...@gmail.com> Sent: Thursday, December 17, 2015 6:07 AM To: Nikos Mavrogiannopoulos Cc: tls@ietf.org; Simon Josefsson Subject: Re

Re: [TLS] Data volume limits

On Wed, 2015-12-16 at 09:57 -1000, Brian Smith wrote: > Therefore, I think we shouldn't add the rekeying mechanism as it is > unnecessary and it adds too much complexity. Any arbitrary limit for a TLS connection is almost guaranteed to cause problems in the future. We cannot predict whether 2^x

Re: [TLS] Data volume limits

> On 17 Dec 2015, at 10:19 AM, Nikos Mavrogiannopoulos wrote: > > On Wed, 2015-12-16 at 09:57 -1000, Brian Smith wrote: > >> Therefore, I think we shouldn't add the rekeying mechanism as it is >> unnecessary and it adds too much complexity. > > Any arbitrary limit for a TLS

Re: [TLS] Data volume limits

On Wed, Dec 16, 2015 at 2:57 PM, Brian Smith wrote: > Eric Rescorla wrote: >> >> >> I believe Watson provided one a while back at: >> https://www.ietf.org/mail-archive/web/tls/current/msg18240.html > > > So, if [2] is correct, then we can take Watson's 2^36

Re: [TLS] Data volume limits

On Wed, Dec 16, 2015 at 1:14 PM, Blumenthal, Uri - 0553 - MITLL wrote: > On 12/16/15, 12:16 , "Watson Ladd" wrote: > >>On Wed, Dec 16, 2015 at 12:09 PM, Blumenthal, Uri - 0553 - MITLL >> wrote: >>> On 12/16/15, 10:50, "Watson Ladd"

Re: [TLS] Data volume limits

ss of IND property in TLS context leads to a practical attack. >>From: TLS <tls-boun...@ietf.org> on behalf of "Dang, Quynh" >> <quynh.d...@nist.gov> >> Date: Wednesday, December 16, 2015 at 07:21 >> To: Eric Rescorla <e...@rtfm.com>, "tls

Re: [TLS] Data volume limits

property. That's the attack. This is not a weakness in the proven bounds, but a mode limitation. Since you've agreed we can rekey more frequently > > >>>From: TLS <tls-boun...@ietf.org> on behalf of "Dang, Quynh" >>> <quynh.d...@nist.gov> >>> Date: Wed

Re: [TLS] Data volume limits

On Dec 16, 2015 5:26 PM, "Brian Smith" wrote: > > Watson Ladd wrote: > >> Brian Smith wrote: >> > So, if [2] is correct, then we can take Watson's 2^36 and multiply it by >> > 2^17 to get 2^53 bytes as the limit? It seems so,

Re: [TLS] Data volume limits

Watson Ladd wrote: > Brian Smith wrote: > > So, if [2] is correct, then we can take Watson's 2^36 and multiply it by > > 2^17 to get 2^53 bytes as the limit? It seems so, since [2] claims that > > they've improved the bounds by 2^17. Note that 3 out

Re: [TLS] Data volume limits

On Wed, Dec 16, 2015 at 7:07 AM, Henrick Hellström wrote: > On 2015-12-16 12:17, Eric Rescorla wrote: >> >> Can we see a brief writeup explaining the 2^36 number? >> >> >> I believe Watson provided one a while back at: >>

Re: [TLS] Data volume limits

.org<mailto:tls-boun...@ietf.org>> on behalf of Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>> Sent: Wednesday, December 16, 2015 6:17 AM To: Simon Josefsson Cc: tls@ietf.org<mailto:tls@ietf.org> Subject: Re: [TLS] Data volume limits On Wed, Dec 16, 2015 at 12:44 AM

Re: [TLS] Data volume limits

On Wed, Dec 16, 2015 at 12:44 AM, Simon Josefsson wrote: > Eric Rescorla writes: > > > Watson kindly prepared some text that described the limits on what's safe > > for AES-GCM and restricting all algorithms with TLS 1.3 to that lower > > limit (2^{36}

Re: [TLS] Data volume limits

On 2015-12-16 12:17, Eric Rescorla wrote: Can we see a brief writeup explaining the 2^36 number? I believe Watson provided one a while back at: https://www.ietf.org/mail-archive/web/tls/current/msg18240.html One rather obvious problem with trying to equate probability of loss of

Re: [TLS] Data volume limits

2015 6:17 AM To: Simon Josefsson Cc: tls@ietf.org Subject: Re: [TLS] Data volume limits On Wed, Dec 16, 2015 at 12:44 AM, Simon Josefsson <si...@josefsson.org<mailto:si...@josefsson.org>> wrote: Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>> writes: > Watson k

Re: [TLS] Data volume limits

Eric Rescorla writes: > Watson kindly prepared some text that described the limits on what's safe > for AES-GCM and restricting all algorithms with TLS 1.3 to that lower > limit (2^{36} bytes), even though ChaCha doesn't have the same > restriction. Can we see a brief writeup

Re: [TLS] Data volume limits

On Tue, 15 Dec 2015 13:14:30 -0800 Eric Rescorla wrote: > Watson kindly prepared some text that described the limits on what's > safe for AES-GCM and restricting all algorithms with TLS 1.3 to that > lower limit (2^{36} bytes), even though ChaCha doesn't have the same >

Re: [TLS] Data volume limits

> On 15 Dec 2015, at 22:17, Watson Ladd wrote: > > I don't think that's what I intended: I think the limit should be > ciphersuite specific. Unfortunately that requires more work. > > On Tue, Dec 15, 2015 at 4:15 PM, Eric Rescorla wrote: >> >>> I wanted

Re: [TLS] Data volume limits

On Behalf Of *Eric Rescorla > *Sent:* Tuesday, December 15, 2015 4:15 PM > *To:* tls@ietf.org > *Subject:* [TLS] Data volume limits > > > > Watson kindly prepared some text that described the limits on what's safe > > for AES-GCM and restricting all algorithms with TLS 1.3

Re: [TLS] Data volume limits

> -Original Message- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Henrick Hellström > Sent: Tuesday, December 15, 2015 7:09 PM > To: tls@ietf.org > Subject: Re: [TLS] Data volume limits > > On 2015-12-16 00:48, Eric Rescorla wrote: > > > > &g

Re: [TLS] Data volume limits

> -Original Message- > From: Watson Ladd [mailto:watsonbl...@gmail.com] > Sent: Tuesday, December 15, 2015 5:38 PM > To: Scott Fluhrer (sfluhrer) > Cc: Eric Rescorla; tls@ietf.org > Subject: Re: [TLS] Data volume limits > > On Tue, Dec 15, 2015 at 5:01 PM,

Re: [TLS] Data volume limits

) > > Cc: Eric Rescorla; tls@ietf.org > > Subject: Re: [TLS] Data volume limits > > > > On Tue, Dec 15, 2015 at 5:01 PM, Scott Fluhrer (sfluhrer) > > <sfluh...@cisco.com> wrote: > > > Might I enquire about the cryptographical reason behind such a l

Re: [TLS] Data volume limits

Watson Ladd wrote: > The issue is the bounds in Iwata-Ohashai-Minematsu's paper, which show > a quadratic confidentiality loss after a total volume sent. This is an > exploitable issue. > Please explain in more detail how you got "2^36 bytes" for a nonce size of 96 bits

Re: [TLS] Data volume limits

On 2015-12-16 01:31, Watson Ladd wrote: You don't understand the issue. The issue is PRP not colliding, whereas PRF can. Oh, but I concur. This means that if you observe two same valued cipher text blocks, you know that the corresponding key stream blocks can't be identical, and deduce that

Re: [TLS] Data volume limits

Of Eric Rescorla Sent: Tuesday, December 15, 2015 4:15 PM To: tls@ietf.org Subject: [TLS] Data volume limits Watson kindly prepared some text that described the limits on what's safe for AES-GCM and restricting all algorithms with TLS 1.3 to that lower limit (2^{36} bytes), even though ChaCha doesn't

Re: [TLS] Data volume limits

On Tue, Dec 15, 2015 at 7:59 PM, Henrick Hellström wrote: > On 2015-12-16 01:31, Watson Ladd wrote: >> >> You don't understand the issue. The issue is PRP not colliding, whereas >> PRF can. > > > Oh, but I concur. This means that if you observe two same valued cipher text >

Re: [TLS] Data volume limits

On 16 December 2015 at 14:01, Brian Smith wrote: > Martin Thomson wrote: > Why? If there were a stupidly high limit, then I would argue for no rekeying facility. But the numbers Watson ran suggested that GCM starts to look shaky at 2^36. That's

Re: [TLS] Data volume limits

RC4 does not rekey per application layer fragment in TLS. The same key is used for the duration of a connection. Other protocols using RC4 do rekey per packet, eg WEP and WPA/TKIP. Cheers Kenny > On 16 Dec 2015, at 16:37, Ryan Carboni wrote: > > How often does TLS rekey