Re: [TLS] Key update routine

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

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: [e-mail]
Subject: Re: [TLS] Key update routine

On Fri, Apr 28, 2017 at 07:41:59PM +0100, Ken Ivanov wrote:
> Hi Eric and everyone,
>
> 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).

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