From f5d3142efb5ae15acdce5aa7c7aad7bc8359dd67 Mon Sep 17 00:00:00 2001 From: John-Mark Gurney Date: Sun, 30 Jan 2022 21:22:15 -0800 Subject: [PATCH] move key negotiation to common section, define ecdhe --- PROTOCOL.md | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/PROTOCOL.md b/PROTOCOL.md index 12e3298..8824b34 100644 --- a/PROTOCOL.md +++ b/PROTOCOL.md @@ -22,7 +22,16 @@ Key Negotiation Where type is to be: shared - shared secret ecdh - Results of an ECDH exchange, key = K || K_A || K_B - ecdhe - Results of an ECDHE exchange, key = TBD + ecdhe - Ephemeral keys + static keys for PFS + +In order to handle a reset and prevent a replay attack, an existing +session, if any is maintained till the completion of a reset request +aka new key negotiation completes. Only after that, does the old +connection key get removed. This does mean that after a reset request, +it is required that both sides attempt to decode each packet w/ both +states. This is safe as it is assumed that the initiator will not +initiate a new key negotiation unless it wants it's previous session +to be removed. ### shared @@ -77,13 +86,7 @@ It seems odd to respond to the confirm message, BUT, as using strobe requires explicit hand off (similar to a token), in order for the initiator to send any commands it needs to be "passed back". -The new key/session does not become active till this point. - -In order to handle a reset and prevent a replay attack, the existing -session, if any is maintained till the completion of a reset request. -Only after that, does the old connection key get removed. This does -mean that after a reset request, it is required that both sides attempt -to decode each packet w/ both states. +At this point, the new key/session becomes active. Command Phase -------------