Subject: [core] draft-hartke-core-stateless

From: Jim Schaad <[email-masked]>
Date: Mon, 10 Sep 2018 16:07:48 -0700

Section 2.2.2 - Depending on circumstances, I think you might get a Gateway
time out error response as well for some types of proxies.

Section 2.2.2 - Should there be a special indicator that a server cannot
deal with tokens of longer than n bytes?  Otherwise this would seem to be a
good way to exhaust resources on the server/proxy.

Section 3.1 - I would think that repeatable would be better for the option
as then multiple proxies could just insert a new option rather than
attempting to extend or wrap the current value.

Section 3.1 - I am not sure that I agree that the option should be unsafe to
forward.  As long as a client and a server agree to deal with the option
then it does not matter what any intermediate proxies might do.  Changing
this modifies 3.2.2 as well

Section 3.1 - above two arguments would change the values of critical as
well.  I still think that it would be part of the cache key for a proxy that
did not understand the option, it might be noted that a proxy which
understands the option would be in its right to exclude the option from
computing the cache key.

Section 3.1 - The last sentence may need to have some additional text added
about the length of the Token field when splitting the value.  Also needs to
have a note about the interactions messages in those cases where the portion
placed in the token field does not change.  This seems quite possible if one
uses a prefix.

Section 4 - What happens for interactions w/ the observe option?

Section 4.1 - I don't see how paragraph 3 follows from the use of this
option.  This is merely a tree statement for all intermediaries that don't
bother caching.  Note that if the intermediary does cache responses, but
does not cache this option then the entire paragraph does not seem to be
correct.  It could respond from the cache, but not worry about keeping this
value in the cache and trying to figure out when and how to ignore.

Security Considerations - Need additional text someplace about swapping of
tokens which might be more consequential than would normally be the case.

Someplace - Interactions between OSCORE and this new option.

Freshness indicator may need to be dealt with on a per server basis or using
the same type of window that DTLS uses.  If a client sends out two different
messages to two different servers, the order of responses should not control
if a response is processed.

Jim

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 11 Sep 2018 15:11:25 +0200

Hello Klaus,

> this modifies 3.2.2 as well

I also think that the option can be safe to forward -- as long as the
origin server replies with the "option part" of the token, the proxy
will return the full original request identity (token plus option part)
back.

Either way, one could add that a proxy is free to take responsibility of
the Extended-Token itself, make a note to insert it into the response,
and forward the request without any Extended-Token, relieving the origin
server of the responsibility to deal with the critical option. (I figure
that any non-constrained proxy would want to do that, as it limits the
way a Extended-Token request can fail).

Best regards
Christian`

-- 
I shouldn't have written all those tank programs.
  -- Kevin Flynn

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 11 Sep 2018 13:31:14 +0000

Christian Amsüss wrote:
> I also think that the option can be safe to forward -- as long as the origin
> server replies with the "option part" of the token, the proxy will return the
> full original request identity (token plus option part) back.

Right, proxies could simply forward the extended tokens in the requests and responses generated by clients and servers. But proxies also generate responses themselves, e.g., from cached responses or in case of errors (5.02, 5.04). We don't want clients to receive the extended token from another client or no extended token at all when a proxy does not support the option.

I can't think of any way to get sensible behavior without the proxies understanding what's going on.

Klaus

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 11 Sep 2018 15:40:47 +0200

Hello Klaus,

On Tue, Sep 11, 2018 at 01:31:14PM +0000, Klaus Hartke wrote:
> But proxies also generate responses themselves, e.g., from cached
> responses or in case of errors (5.02, 5.04). We don't want clients to
> receive the extended token from another client or no extended token at
> all when a proxy does not support the option.

As long as the option is part of the cache key, any cached response
would need to have a matching request Extended-Token and thus would have
a matching response Extended-Token as well.

If those, by any chance, match up between two different staetless
proxies, *and* if there is a cached fresh response available, then so be
it, may the new request receive the original response. After all, it is
fresh, and the response Extended-Token returned is exactly the one
requested. If both requesting stateless proxies were stateful ones,
neither request would have a Extended-Token option, and the second
client would receive the cached request just as well.

(This is about the astronomically unlikely case of a collision in the
integrity protected tokens; it's way more likely that the stateless
proxy re-requested the resource on behalf of the very same origin if
such a cache hit happens. But still, even if, it'd be OK).

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: Tue, 11 Sep 2018 08:39:34 -0700

> -----Original Message-----
> From: Klaus Hartke <[email-masked]>
> Sent: Tuesday, September 11, 2018 6:31 AM
> To: Christian Amsüss <[email-masked]>; draft-hartke-core-
> [email-masked]
> Cc: Jim Schaad <[email-masked]>; 'Core' <[email-masked]>
> Subject: RE: [core] draft-hartke-core-stateless
> 
> Christian Amsüss wrote:
> > will return the full original request identity (token plus option part) back.
> 
> Right, proxies could simply forward the extended tokens in the requests and
> responses generated by clients and servers. But proxies also generate
> responses themselves, e.g., from cached responses or in case of errors (5.02,
> 5.04). We don't want clients to receive the extended token from another client
> or no extended token at all when a proxy does not support the option.
> 

If the option is part of the cache key for proxies which do not understand the option then you will not have that problem.

Jim

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 12 Sep 2018 08:35:23 +0000

Christian Amsüss wrote:
> As long as the option is part of the cache key, any cached response would
> need to have a matching request Extended-Token and thus would have a
> matching response Extended-Token as well.

I don't think it's very desirable to require tokens to match when serving a cached response.

And there's still the other half of the problem: An unaware proxy won't include the option in responses it generates itself.

Klaus

---

From: Jim Schaad <[email-masked]>
Date: Wed, 12 Sep 2018 07:56:03 -0700

> From: core <[email-masked]> On Behalf Of Klaus Hartke
> Sent: Wednesday, September 12, 2018 1:35 AM
> To: 'Core' <[email-masked]>
> Subject: Re: [core] draft-hartke-core-stateless
> 
> Christian Amsüss wrote:
> > > responses or in case of errors (5.02, 5.04). We don't want clients
> > > to receive the extended token from another client or no extended
> > > token at all when a proxy does not support the option.
> >
> > would need to have a matching request Extended-Token and thus would
> > have a matching response Extended-Token as well.
> 
> And there's still the other half of the problem: An unaware proxy won't include
> the option in responses it generates itself.

Reiterate -

For an unaware proxy having the item as part of the cached key prevents it from generating responses itself.

Text which says that aware proxies can omit the option from the cached key allows them to generate responses out of the cache and they will know that they need to process and return the option.

Jim

> 
> Klaus
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 12 Sep 2018 14:59:49 +0000

> from generating responses itself.

An unaware proxy would still generate 5.02 and 5.04 responses itself.

Klaus

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 18 Sep 2018 08:31:53 +0000

Hi Jim,

thanks for the thorough review! I've just submitted revision -01 with some clarifications.

> time out error response as well for some types of proxies.

Could you give an example? To me it seems that a message format error or unsupported critical unsafe-to-forward option will reliably give a Reset message or Bad Option response from the next hop.

> Section 2.2.2 - Should there be a special indicator that a server cannot deal
> with tokens of longer than n bytes?  Otherwise this would seem to be a good
> way to exhaust resources on the server/proxy.

This is a very good question and a point that needs discussion in the WG. We could mandate a fixed upper limit that all implementations of the draft must support, or try to come up with some maximum length token detection/negotiation.

> Section 3.1 - I would think that repeatable would be better for the option as
> then multiple proxies could just insert a new option rather than attempting
> to extend or wrap the current value.
> 
> forward.  As long as a client and a server agree to deal with the option then it
> does not matter what any intermediate proxies might do.  Changing this
> modifies 3.2.2 as well
> 
> Section 3.1 - above two arguments would change the values of critical as well.
> I still think that it would be part of the cache key for a proxy that did not
> understand the option, it might be noted that a proxy which understands the
> option would be in its right to exclude the option from computing the cache
> key.
> 
> have a note about the interactions messages in those cases where the
> portion placed in the token field does not change.  This seems quite possible
> if one uses a prefix.

I'm skipping these points as Section 3/Variant B is removed in revision -01.

> Section 4.1 - I don't see how paragraph 3 follows from the use of this option.
> This is merely a true statement for all intermediaries that don't bother
> caching.  Note that if the intermediary does cache responses, but does not
> cache this option then the entire paragraph does not seem to be correct.  It
> could respond from the cache, but not worry about keeping this value in the
> cache and trying to figure out when and how to ignore.

Good observation. I've rephrased this part in revision -01. Could you take a look?

> tokens which might be more consequential than would normally be the case.

Text contributions to the draft are highly welcome :)

> Someplace - Interactions between OSCORE and this new option.

I don't think there are any interactions with OSCORE.

> if a response is processed.

Text contributions to the draft are highly welcome :)

Klaus