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
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
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
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
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
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
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
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
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
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
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
11 matches
Mail list logo