From 5330896c0e8023053d4cd15961b2ae0482686ca6 Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Mon, 28 Sep 2026 15:48:04 +0200 Subject: fix: refuse an unsigned handshake challenge Every node the 4.0 floor admits signs its challenge, and one without a channel binding could not complete the proof anyway, so a missing signature is refused like a wrong one (browser and QUIC client). Co-Authored-By: Claude Opus 5.5 --- docs/MESHBAY_NODE_PROTOCOL.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) (limited to 'docs/MESHBAY_NODE_PROTOCOL.md') diff --git a/docs/MESHBAY_NODE_PROTOCOL.md b/docs/MESHBAY_NODE_PROTOCOL.md index 34e2464..642e966 100644 --- a/docs/MESHBAY_NODE_PROTOCOL.md +++ b/docs/MESHBAY_NODE_PROTOCOL.md @@ -549,13 +549,12 @@ this is the key the client wanted. A client with no expectation learns nothing m than before, and the ack remains the proof of GEK possession. Client rule, from the node's answer and never from its version (§13): a `sig` that -does not verify is a refusal (`Node challenge signature invalid`); no `sig` leaves the -key unproved until the ack, and a client holding an invitation-link code then refuses -to send it. A node signs whenever it has a binding, and a node with none sends no -signature rather than an unbound one — the proof would be refused on that connection -anyway. With the floor at 4.0 every peer a client can reach signs, so an absent `sig` -no longer means an older node: the client's handling of it is a branch only a lowered -floor could make reachable again. +does not verify is a refusal (`Node challenge signature invalid`), and so is a +challenge with no `sig` at all. A node signs whenever it has a binding, and a node +with none sends no signature rather than an unbound one — its proof would be refused +on that connection anyway, so refusing the unsigned challenge only says so earlier. +With the floor at 4.0 every peer a client can reach signs, and there is no "older +node" case to tolerate. ### 6.6 `handshake_ack` fields -- cgit v1.2.3