Re: [core] No-Response option and OSCORE

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: core <[e-mail]> On Behalf Of Christian Amsüss
> Sent: Thursday, May 10, 2018 4:41 AM
> To: Francesca Palombini <[e-mail]>
> Cc: [e-mail]; [e-mail]; Klaus
Hartke
> <[e-mail]>
> 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?
> 
> 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.

This is a huge problem and needs to be solved.

> 
> 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 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".
> (RFC7967 has no provisions what to do if No-Response is known but its
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
> 
> --
> To use raw power is to make yourself infinitely vulnerable to greater
powers.
>   -- Bene Gesserit axiom