Echo recovery in multicast cases

[chrysn]

As I understand the current master, replay window recovery should work like this:

• A single server reboots
• Client sends request
• Most servers accept it
• A single server says "4.01 Echo: blah"
• Client sends the same request again to that particular server. It's unicast on the network, uses the same group security context as the original request but has an Echo: blah option and obviously a new sender sequence number.

This triggers the very concerns of ssec-unicast-requests -- someone might send that message to other servers.

(Admittedly that's not a concern for safe requests -- but then again, if it were a safe request, as a server, I'd be tempted to respond successfully right away).

[gselander]

Is this still a concern with pairwise request? (See latest github.)

[chrysn]

I think that pairwise would mitigate this, but that means that pairwise becomes mandatory for challenge-response synchronization.

If that is a restriction that is inacceptable (don't know how big a part of group OSCORE pairwise will be), there might be a variation on ssec-synch-challenge-response that can do without: A server, rather than protected 4.01+Echo, might answer unprotected 5.03 (or not at all if multicast), and send an arbitrary request (I'd send GET / Block2:0:0:0 but it really doesn't matter) to the client (or even the whole group of clients if it just comes up and wants to do that eagerly). If that is responded to with an own sequence number (which'll be the case in groupcomm -- on original OSCORE we couldn't enforce that), that is known fresh to the original server, and it can initialize its replay window. This depends on the availability of role reversal and the absence of proxies, so I'd only flesh this out if it solves a real problem.

[gselander]

Just on pairwise: For the algorithms that are expected to be used, the same public key can be used for both signature and pairwise DH. Therefore the only practical limitation of using pairwise seems to be the inability for intermediary nodes to verify responses, since there is no signature. I think verifying signature makes more sense in multicast requests than in unicast responses, so I think this limitation is acceptable. Why not mandate or at least recommend the use of pairwise DH for responses, and mandate it for challenge-response synchronization?

[chrysn]

Why not mandate or at least recommend the use of pairwise DH for responses, and mandate it for challenge-response synchronization?

If I understand that right that'd be a quite impactful change on group OSCORE, that's probably better tracked in a separate thread / issue.

For the purpose of receive window recovery, using pairwise is probably good enough to close this issue with some text; from looking in a bit deeper, the cost of calculating the pairwise key appears to be in the same order of magnitude as processing a signed response -- and if pairwise is to become even more widespread, it'll just be less impact to code size for echo recovery.