Re: [TLS] KeyUpdate and unbounded write obligations

2016-08-28 Thread Eric Rescorla
On Sun, Aug 28, 2016 at 11:41 AM, Ilari Liusvaara wrote: > On Sun, Aug 28, 2016 at 10:53:14AM -0700, Eric Rescorla wrote: > > > > I'd prefer to keep things as simple as possible here and from that > > perspective, I think any indicator from side A to side B that it wants a > > key change over and

Re: [TLS] KeyUpdate and unbounded write obligations

2016-08-28 Thread Ilari Liusvaara
On Sun, Aug 28, 2016 at 10:53:14AM -0700, Eric Rescorla wrote: > > I'd prefer to keep things as simple as possible here and from that > perspective, I think any indicator from side A to side B that it wants a > key change over and above the KeyUpdate is extra complexity. I do, however, > want to r

Re: [TLS] KeyUpdate and unbounded write obligations

2016-08-28 Thread Eric Rescorla
I'd like to close this discussion if we can. I'd prefer to keep things as simple as possible here and from that perspective, I think any indicator from side A to side B that it wants a key change over and above the KeyUpdate is extra complexity. I do, however, want to retain the property that one

Re: [TLS] Document on increasing the lifetime of session keys

2016-08-28 Thread Stanislav V. Smyshlyaev
‎Dear Eric,Thank you for your comment - indeed, re-keying mechanisms based on secret state are widely used in the protocols (key trees are usual practice in ESP with GOSTs for more than 10 years, for example). My

Re: [TLS] [Cfrg] 3DES diediedie

2016-08-28 Thread Peter Gutmann
Stephen Farrell writes: >IIRC the IoT marketing term doesn't have a very long history so I don't >really know what substance lies behind that remark. I just used "IoT" because someone else had used it, since it's about as well- defined as "Web 2.0" I agree that it's not terribly useful to define

Re: [TLS] Document on increasing the lifetime of session keys

2016-08-28 Thread Eric Rescorla
Stanislav, TLS 1.3 incorporates a rekeying mechanism (KeyUpdate) similar to that if Abdalla and Bellare 1(b). -Ekr On Sun, Aug 28, 2016 at 3:48 AM, Stanislav V. Smyshlyaev wrote: > Dear colleagues, > > Since there is a considerable interest to the question of increasing > session keys lifetim

Re: [TLS] [Cfrg] 3DES diediedie

2016-08-28 Thread Stephen Farrell
Peter, On 28/08/16 13:01, Peter Gutmann wrote: > David McGrew (mcgrew) writes: > >> I don’t think you understood my point. IoT is about small devices connecting >> to the Internet, and IETF standards should expect designed-for-IoT crypto to >> be increasingly in scope. It is important to not f

Re: [TLS] [Cfrg] 3DES diediedie

2016-08-28 Thread Peter Gutmann
Karthikeyan Bhargavan writes: >If every message IoT device sends is a 16 bytes message consisting of one 8 >byte secret and one 8 byte known plaintext, then with a 64-bit cipher, we >only need roughly 64GB in order to get a meaningful collision (50% chance of >recovering the secret). The 768GB va

Re: [TLS] [Cfrg] 3DES diediedie

2016-08-28 Thread Peter Gutmann
David McGrew (mcgrew) writes: >I don’t think you understood my point. IoT is about small devices connecting >to the Internet, and IETF standards should expect designed-for-IoT crypto to >be increasingly in scope. It is important to not forget about these devices, >amidst the current attention be

Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)

2016-08-28 Thread Peter Gutmann
Ryan Hamilton writes: >Alternatively, someone could write a "Legacy TLS" to "Current TLS" proxy, >which could run on the client's computer to sit in front of these legacy >devices. This would allow browsers to continue adding new security features >to protect users, while still allowing access to

[TLS] Document on increasing the lifetime of session keys

2016-08-28 Thread Stanislav V. Smyshlyaev
Dear colleagues, Since there is a considerable interest to the question of increasing session keys lifetime (several productive off-the-list personal discussions about CryptoPro key meshing algorithms and http://eprint.iacr.org/2016/628 started after the Friday posting), maybe we should think abou