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