Subject: [TLS] Key update routine

From: "Ken Ivanov" <[email-masked]>
Date: Fri, 28 Apr 2017 19:41:59 +0100

Hi Eric and everyone,

Glad to meet you all here in this group.

I've been working my way through the latest TLS 1.3 draft (the 20th), and I 
hope you wouldn't mind me putting in my 2p about the key update routine.

While section 4.6.3 (Key and IV update) provides good insight as to what the 
implementations should do if everything goes right, it is unclear on what 
they should do if something goes wrong.

Specifically, while the spec instructs the party that receives a KeyUpdate 
with its request_update set to update_requested to respond with its own 
KeyUpdate with request_update set to update_not_requested, there are no 
provisions as to what the originator of the key update should do if it never 
receives the requested KeyUpdate response from the remote party (or does not 
receive it within a reasonable time scope).

As, following the spec, the originator will be prepared to, I'm going to 
quote it here, 'receive an arbitrary number of messages between sending a 
KeyUpdate with request_update set to update_requested and receiving the peer’s 
KeyUpdate, because those messages may already be in flight,' I am afraid 
this might lead to various implementation mistakes where the implementations 
will simply wait for the KeyUpdate response to come in infinitely, thus 
creating a security flaw (the inbound key may never get actually updated). I 
guess we need clearer rules here, for the sabotage of the remote party to 
participate in the key update routine wasn't tolerated.

We probably also need a well-defined cap on how many key update requests are 
allowed to be sent within a given time frame, as excessive key update 
requests from clients may consume valuable server resources. Such cap will 
also be helpful against buggy implementations which will always be 
responding to the other's KeyUpdate messages with their own request_update 
set to update_requested, effectively creating an endless loop of key 
updates.

Hope this makes sense.

Thanks in advance.

Kind regards,

Ken Ivanov
EldoS Corporation

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 28 Apr 2017 22:03:22 +0300

> receive it within a reasonable time scope).

The problem is that any time bound would cause keyupdate to couple the
directions, which is harmful from API standpoint.

The KeyUpdate mechanism is explicitly designed for fully asynchronous
operation. Which impiles there is no time bound.

-Ilari

---

From: "Ken Ivanov" <[email-masked]>
Date: Fri, 28 Apr 2017 21:24:13 +0100

Hi Ilari

I see your point, thank you. Maybe we shall think about replacing the MUST 
(in 'then the receiver MUST send a KeyUpdate of its own') with SHOULD then, 
not to lead the originator into confusion about the mutual nature of the key 
update, and treat the 'request_update' parameter as a suggestion rather than 
a request? Besides taking the question of enforcing that MUST off the scene, 
this would level the things up and make each direction truly independent.

Ken

-----Original Message----- 
From: Ilari Liusvaara
Sent: Friday, April 28, 2017 8:03 PM
To: Ken Ivanov
Cc: [email-masked]
Subject: Re: [TLS] Key update routine

-Ilari