Capability is signalled in-band by an empty answer: a peer that does not run the
KEM answers with no payload. But a responder that runs the KEM and simply fails
to build the answer (crypto error, failed PSK program, a future protocol version
it cannot parse) also produced an empty payload, so the initiator read it as
"peer has no KEM" and marked it non-capable — permanently, since only peer
removal clears the flag; in strict mode the peer stayed blocked.
Add a payload-less MsgError marker. On a signalling-path failure the responder
returns the marker instead of an empty answer, and the initiator treats it as
"capable but failed this round": it leaves the exchange to time out and
re-bootstrap rather than marking the peer non-capable. A genuinely non-KEM peer
still sends no payload at all, so the empty-answer capability signal is unchanged.
Found in cubic review on #7098 (client/internal/pqkem_adapter.go:72).
We clock the next Offer initiation to the OnDataPathRekeyed, so we have 2 minutes
ahead of us to do our attempts and stuff before to give up.
On failure, we will know because we will not receive a new answer.. but more importantly
the wg handshake will fail :D
riccardom