[TLS] Key update routine

["Ken Ivanov" <[e-mail]>]

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