Subject: Re: [core] No-Response option and OSCORE

From: Christian Amsüss <[email-masked]>
Date: Thu, 10 May 2018 13:41:02 +0200

Hello Francesca,

I've been reviewing the current OSCORE and stumbled upon the No-Resposne
section I had previousy missed when working through the deltas.

Göran mentioned that No-Response had been discussed so I read through
tis thread but found no points addressing those specific concerns --
could you have a look at those notes?

On Mon, Jan 15, 2018 at 01:34:28PM +0000, Francesca Palombini wrote:
> Considering the part I had missed about congestion control, my new
> proposal is: the client must set No-Response as inner and outer.

(Roughly copied from an earlier mail to Göran)

Why must this be set to the same as the current draft says? Assume I'm
updating some value regularly and don't particularly care about short
network outages as the next value will be sent soon anyway, but I do
want to know when the server won't accept any more updates. I would want
to send a protected "NON POST No-Response:2.xx" request.

If I, as prescribed, set No-Response:2.xx both outer and inner, then if
the server answers protected-4.04 (which is outer-2.01), then the server
may know to ignore the outer No-Response, but a surprised proxy would
not and swallow the 4.04.

If only an inner No-Response:2.xx is were sent, the proxy expects an
unconditional response, and might respond late with a 5.04 Gateway
Timeout. (That's also bad but not as bad as the above).

I'd suggest picking an outer value that is not specified yet (say, "1",
and call it "at the origin's disretion"). Without proxies, this will be
ignored and the origin looks at the inner one. Proxies would either fail
with Bad Option (which can be a desirable outcome, given that otherwise
they won't be behaving properly) or (hopefully) forward it as "I know
that this is a No-Response, I can't tell the condition, but I'm prepared
to receive a response if one comes along but no response is OK as well".
(RFC7967 has no provisions what to do if No-Response is known but its
value unspecified).

It's late and this is not a well-thought-through suggestion, so feel
free to ignore it. (Turns out it's not easy to make OSCORE work through
proxies, but then again, that's why we have it.)

Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Jim Schaad <[email-masked]>
Date: Thu, 10 May 2018 11:20:31 -0700

> -----Original Message-----
> From: core <[email-masked]> On Behalf Of Christian Amsüss
> Sent: Thursday, May 10, 2018 4:41 AM
> To: Francesca Palombini <[email-masked]>
> Cc: [email-masked]; [email-masked]; Klaus
Hartke
> <[email-masked]>
> Subject: Re: [core] No-Response option and OSCORE
> 
> Hello Francesca,
> 
> I've been reviewing the current OSCORE and stumbled upon the No-
> Resposne section I had previousy missed when working through the deltas.
> 
> Göran mentioned that No-Response had been discussed so I read through tis
> thread but found no points addressing those specific concerns -- could you
> have a look at those notes?
> 
> network outages as the next value will be sent soon anyway, but I do want
to
> know when the server won't accept any more updates. I would want to send
> a protected "NON POST No-Response:2.xx" request.
> 
the
> server answers protected-4.04 (which is outer-2.01), then the server may
> know to ignore the outer No-Response, but a surprised proxy would not and
> swallow the 4.04.

This is a huge problem and needs to be solved.

> Timeout. (That's also bad but not as bad as the above).

I am not sure that I worry about this.  First I think that the proxy in this
case is being overly helpful.  Given that we are looking at a NON request,
it makes sense that there is no response ever coming back from anybody.  It
would be different if this were a CON request.  You are going to get the
exact same behavior from a proxy which does not implement the No-Response
option so this is not going to be new.

> I'd suggest picking an outer value that is not specified yet (say, "1",
and call it
> "at the origin's disretion"). Without proxies, this will be ignored and
the origin
> looks at the inner one. Proxies would either fail with Bad Option (which
can
> be a desirable outcome, given that otherwise they won't be behaving
> properly) or (hopefully) forward it as "I know that this is a No-Response,
I
> can't tell the condition, but I'm prepared to receive a response if one
comes
> along but no response is OK as well".
value
> unspecified).

If you are going to do this, it might be better to say that you are not
interested in 8.xx messages which could be defined as being - no proxies are
to generate responses.

Jim

> 
> It's late and this is not a well-thought-through suggestion, so feel free
to
> ignore it. (Turns out it's not easy to make OSCORE work through proxies,
but
> then again, that's why we have it.)
> 
> Best regards
> Christian
> 
> --

---

From: 'Christian Amsüss' <[email-masked]>
Date: Fri, 11 May 2018 12:37:45 +0200

Hi jim and OSCORE developers,

On Thu, May 10, 2018 at 11:20:31AM -0700, Jim Schaad wrote:
> > If I, as prescribed, set No-Response:2.xx both outer and inner, then
> > if the server answers protected-4.04 (which is outer-2.01), then the
> > server may know to ignore the outer No-Response, but a surprised
> > proxy would not and swallow the 4.04.
> 

Glad I did not just miss an old solution.

> would be different if this were a CON request.

The proxy might have forwarded it as a CON, or over reliable transport.

> You are going to get the exact same behavior from a proxy which does
> not implement the No-Response option so this is not going to be new.

I don't think so. No-Response is unsafe-to-forward, so it "lead[s] to
4.02 Bad Option" per RFC7252 Section 5.7.1.

> > I'd suggest picking an outer value that is not specified yet (say,
> > "1", and call it "at the origin's disretion"). [...]
> 

Indeed, expressing the code as 0x80 is better; there can never be 8.xx
codes so this is obviously magic, while someone could still define 1.xx
codes to be ignored.

Bringing this to concrete proposals:

A: the simple one

"No-Response is an inner and outer option; the inner option always
reflects the intention of the operation, and an OSCORE server ignores
the outer. A client usually sets only the inner No-Response option, but
MAY set the outer to 26 ('ignore all known codes') if the inner is set
to 26. The client MUST be prepared to receive and discard 5.04 errors
from intermediaries."

B: extend No-Response

"We define a new No-Response value, 128, described as 'Not interested in
some responses'. A server receiving that option decides based on some
context (eg. other options like OSCORE) whether or not the client is
interested in the response; if it has no such context, it SHOULD respond
with 4.02 Bad Option. A proxy processing the option must forward
response messages it receives, but never sends a 5.04 error if it
receives no response. (It may still send a 5.04 if it forwards the
request over a secure or reliable connection that can not be
established, or if it forwards the request as a CON and receives no
ACK.)

No-Response is an inner and outer option; [... as above]. If a client
sets the inner option, itSHOULD set the outer option to 128 ('Not
interested in some responses'), or be prepared to receive and discard
5.04 errors from intermediaries."

Best regards
Christian

---

From: Jim Schaad <[email-masked]>
Date: Fri, 11 May 2018 08:39:04 -0700

I believe that this is correct.  I am agnostic as to which solution is
chosen.

Jim

> From: 'Christian Amsüss' <[email-masked]>
> Sent: Friday, May 11, 2018 3:38 AM
> To: Jim Schaad <[email-masked]>
> Cc: 'Francesca Palombini' <[email-masked]>; draft-tcs-
> [email-masked]; [email-masked]; 'Klaus Hartke'
> <[email-masked]>
> > I am not sure that I worry about this.  First I think that the proxy
> > in this case is being overly helpful. Given that we are looking at a
> > NON request, it makes sense that there is no response ever coming back
> > from anybody.  It would be different if this were a CON request.
> 
> > If you are going to do this, it might be better to say that you are
> > not interested in 8.xx messages which could be defined as being - no
> > proxies are to generate responses.
> 
codes
> so this is obviously magic, while someone could still define 1.xx codes to
be
> ignored.
reflects
> the intention of the operation, and an OSCORE server ignores the outer. A
> client usually sets only the inner No-Response option, but MAY set the
outer
> to 26 ('ignore all known codes') if the inner is set to 26. The client
MUST be
> prepared to receive and discard 5.04 errors from intermediaries."
> 
> B: extend No-Response
> 
with
> 4.02 Bad Option. A proxy processing the option must forward response
> messages it receives, but never sends a 5.04 error if it receives no
response.
> (It may still send a 5.04 if it forwards the request over a secure or
reliable
> connection that can not be established, or if it forwards the request as a
CON
> and receives no
> ACK.)
> 
> No-Response is an inner and outer option; [... as above]. If a client sets
the
> inner option, itSHOULD set the outer option to 128 ('Not interested in
some
> responses'), or be prepared to receive and discard