chrysn
commented
4 years ago I've written up #48 to address the issue we received comments on.
On the topic of endpoints, I found that the text already clearly separates the use case of "client aliveness" and "network reachability"; I've added a word on the aliveness being a cryptographic property and not just another word for the network address being in service, which is hopefully enough for the confusion that has arisen. No need to make things more complicated by pointing out the two server endpoints that are still around there: we never talk of properties that either can have (client aliveness is about the protected endpoint, network reachability is about the unprotected one).
If you're happy with #48, I think we can close this.
emanjon
(from today's telco) "client aliveness" questions lead to the question of who is the client, and from there to which endpoints are involved.
From RFC7252's endpoint definition, the security association is part of it. So there are two endpoints involved, the hop-by-hop endpoint (which has no security, or possibly the security of a wrapping DTLS connection) and the end-to-end endpoint (which is OSCORE protected), which may or may not reside on the same host. Different positions of the Echo option relate to communication with different endpoints.
It'd be easier to describe the Echo option behavior if that distinction were made explicit in OSCORE, and I don't want to introduce too much of new concepts in here where they don't belong -- finding text to address that might be tricky.
(Once words are found to describe that in the Echo text, we'll also have the words to talk about the independent alivenesses of the endpoints, and say that for cryptographically showing "client aliveness" (that's a term there), the aliveness of the inner endpoint must be shown).