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: tls@ietf.org
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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
