[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 have the same restriction. I wanted to get people's opinions on whether that's actually what we want or w

Re: [TLS] Data volume limits

For context, see: https://github.com/tlswg/tls13-spec/pull/372 On Tue, Dec 15, 2015 at 1:14 PM, 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 th

Re: [TLS] Data volume limits

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: > For context, see: > https://github.com/tlswg/tls13-spec/pull/372 > > On Tue, Dec 15, 2015 at 1:14 PM, Eric Rescorl

Re: [TLS] Data volume limits

On Tue, Dec 15, 2015 at 1:17 PM, 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. > That makes sense. Do you think you'll be able to provide that in the not too distant future? I can just leave t

Re: [TLS] Data volume limits

Personally, I think a hard requirement to rekey every 64GiB is reasonable enough to just use it for every cipher. I don't think cipher-specific requirements are worth the effort/complexity. Something like a MUST for AES-GCM and a SHOULD for ChaCha seems fine, though, if really desired. Dave

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 to get people's opinions on whether tha

Re: [TLS] Data volume limits

Might I enquire about the cryptographical reason behind such a limit? Is this the limit on the size of a single record? GCM does have a limit approximately there on the size of a single plaintext it can encrypt. For TLS, it encrypts a record as a single plaintext, and so this would apply to e

Re: [TLS] Data volume limits

On Tue, Dec 15, 2015 at 2:01 PM, Scott Fluhrer (sfluhrer) < sfluh...@cisco.com> wrote: > Might I enquire about the cryptographical reason behind such a limit? > > > > Is this the limit on the size of a single record? GCM does have a limit > approximately there on the size of a single plaintext it

Re: [TLS] Data volume limits

On Dec 15, 2015, at 4:14 PM, 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 > restriction. > > I wanted to ge

Re: [TLS] Data volume limits

On Tue, Dec 15, 2015 at 5:18 PM, Russ Housley wrote: > > On Dec 15, 2015, at 4:14 PM, 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 Ch

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 > restriction. > > I wanted

Re: [TLS] Data volume limits

On Tue, Dec 15, 2015 at 5:01 PM, Scott Fluhrer (sfluhrer) wrote: > Might I enquire about the cryptographical reason behind such a limit? > > > > Is this the limit on the size of a single record? GCM does have a limit > approximately there on the size of a single plaintext it can encrypt. For > T

[TLS] Barry Leiba's No Objection on draft-ietf-tls-cached-info-20: (with COMMENT)

Barry Leiba has entered the following ballot position for draft-ietf-tls-cached-info-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to ht

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, Scott Fluhrer (sfluhrer) > wro

Re: [TLS] Data volume limits

On Dec 15, 2015 6:08 PM, "Scott Fluhrer (sfluhrer)" wrote: > > > > > -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

Re: [TLS] Data volume limits

On Tue, Dec 15, 2015 at 3:08 PM, Scott Fluhrer (sfluhrer) < sfluh...@cisco.com> wrote: > > > > -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 > > Subje

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 from the Iwata-Ohashai-Mi

Re: [TLS] Data volume limits

On 2015-12-16 00:48, Eric Rescorla wrote: On Tue, Dec 15, 2015 at 3:08 PM, Scott Fluhrer (sfluhrer) mailto:sfluh...@cisco.com>> wrote: The quadratic behavior in the security proofs are there for just about any block cipher mode, and is the reason why you want to stay well below the

Re: [TLS] Data volume limits

On Dec 15, 2015 7:09 PM, "Henrick Hellström" wrote: > > On 2015-12-16 00:48, Eric Rescorla wrote: >> >> >> >> On Tue, Dec 15, 2015 at 3:08 PM, Scott Fluhrer (sfluhrer) >> mailto:sfluh...@cisco.com>> wrote: >> The quadratic behavior in the security proofs are there for just >> about any blo

Re: [TLS] Data volume limits

On 12/15/2015 04:08 PM, Henrick Hellström wrote: > On 2015-12-16 00:48, Eric Rescorla wrote: >> >> >> On Tue, Dec 15, 2015 at 3:08 PM, Scott Fluhrer (sfluhrer) >> mailto:sfluh...@cisco.com>> wrote: >> The quadratic behavior in the security proofs are there for just >> about any block ciph

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: > > > > > > On Tue, Dec 15, 2015 at 3:08 PM, Sc

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 t

Re: [TLS] Data volume limits

On 16 December 2015 at 08:14, Eric Rescorla wrote: > > I wanted to get people's opinions on whether that's actually what we want > or whether we should (as is my instinct) allow people to use ChaCha > for longer periods. Whatever the actual limits are, I think that implementatios should be encou

Re: [TLS] Data volume limits

Martin Thomson wrote: > Whatever the actual limits are, I think that implementatios should be > encouraged to rekey more strongly. > Why? > And suggesting a stupidly high limit (e.g., ChaCha being > greater than 2^96) leaves people thinking that they can skip > implementation and testing of th

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 too low for some applications. For the rest of t

Re: [TLS] Data volume limits

On Tue, Dec 15, 2015 at 4: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 blocks, you know that

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 > blocks, you know that t

Re: [TLS] Data volume limits

Hi Watson, On 16/12/15 03:36, Watson Ladd wrote: > The problem is that once you stack enough of those negligible > probabilities together, you end up with something big. Push up to > 2^{63} bytes, and the collision probability is 1/4 or 1/2 (I didn't > recompute it just now). The collision prob

Re: [TLS] Data volume limits

On Tuesday, December 15, 2015 09:40:41 pm Martin Thomson wrote: > In light of that, the actual limits don't matter that much to me. As > David McGrew suggested, set a limit at 2^32 and avoid having to think > too hard about how close to the failure point you might be. +1 In fact, if we're OK wit

Re: [TLS] Data volume limits

On 16 December 2015 at 14:57, Dave Garrett wrote: > In fact, if we're OK with setting this rather low threshold, then we could > even get rid of the rekey signal entirely and just have an automatic rekey > after every 4GiB for all ciphers. That'd be one less complexity to deal with. > Rekeys wo

Re: [TLS] Data volume limits

On Tue, Dec 15, 2015 at 7:59 PM, Martin Thomson wrote: > On 16 December 2015 at 14:57, Dave Garrett wrote: > > In fact, if we're OK with setting this rather low threshold, then we > could even get rid of the rekey signal entirely and just have an automatic > rekey after every 4GiB for all cipher

Re: [TLS] Data volume limits

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 applications are the only ones at risk. If we do, it may be a

Re: [TLS] Data volume limits

On Tuesday, December 15, 2015 10:59:35 pm Martin Thomson wrote: > On 16 December 2015 at 14:57, Dave Garrett wrote: > > In fact, if we're OK with setting this rather low threshold, then we could > > even get rid of the rekey signal entirely and just have an automatic rekey > > after every 4GiB f

Re: [TLS] Data volume limits

On 16 December 2015 at 15:08, Dave Garrett wrote: > We could just make the threshold a configurable parameter, with > default/maximum at 2^32 bytes. Each endpoint could just provide its threshold > in a new extension. Both get to specify what they want and it could be > lowered arbitrarily for

Re: [TLS] Data volume limits

On Tuesday, December 15, 2015 11:11:36 pm Martin Thomson wrote: > On 16 December 2015 at 15:08, Dave Garrett wrote: > > We could just make the threshold a configurable parameter, with > > default/maximum at 2^32 bytes. Each endpoint could just provide its > > threshold in a new extension. Both g

Re: [TLS] Data volume limits

On 12/15/2015 03:47 PM, Watson Ladd wrote: On Dec 15, 2015 6:08 PM, "Scott Fluhrer (sfluhrer)" mailto:sfluh...@cisco.com>> wrote: > > > > > -Original Message- > > From: Watson Ladd [mailto:watsonbl...@gmail.com ] > > Sent: Tuesday, December 15, 2015 5:3

Re: [TLS] Data volume limits

How often does TLS rekey anyway? I know RC4 rekeys per packet, but I've read and searched a fair amount of documentation, and haven't found anything on the subject. Perhaps I'm looking for the wrong terms or through the wrong documents. ___ TLS mailing li

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 anyway? I know RC4