Re: [core] 🔔 WGLC of draft-ietf-core-stateless-01

[Mališa Vučinić <[e-mail]>]

Dear CoRE,

As indicated during the Prague meeting, I would like to thank Klaus and the CoRE group for finalizing this document on a short notice. The stateless document was motivated by our network access use case in 6TiSCH where an unauthenticated client talks to a constrained (stateless) proxy in order to join the network.

In general, I find the document well written and easy to read. Some remarks below. 

In case the extended token and Observe are used together, where multiple (legitimate) Observe responses carry the same (extended) token, replay protection using sequence numbers at the client might falsely identify such tokens as replays. How should this be handled?

Little consideration is given to the replay protection using timestamps. It might be important to note here that a client, and particularly a constrained one, only needs to trust its own clock without any synchronization required. The question that remains though is what implementation strategy should a client use to accept/reject a given extended token when using timestamps.

A client (or intermediary in the role of a client) that depends on
   support for extended token lengths (Section 2) from the next hop to
   avoid keeping request state MUST perform a discovery of support
   (Section 2.2) before it can be stateless.

There are environments, 6TiSCH being one example, where the support for extended tokens can be known before hand, e.g. through out of band information such as dependency in the draft. In that case, saving two messages on the wire in constrained environments by omitting the discovery seems quite reasonable. I would therefore argue for this MUST to be replaced with a SHOULD.

Some nits below:

   If a server supports extended token lengths but receives a request
   with a token of a length it is unwilling or unable to process, it
   MUST NOT reject the message.  Instead, it SHOULD return a 4.00 (Bad
   Request) response.  This implies that the server returns the entire
   token verbatim.

This paragraph to me seems self-contradictory. If a server cannot process a request with a token length greater than some value, is it reasonable to expect that it can return it in the Bad Request response? If SHOULD is not respected, what happens?

 Tokens are a hop-by-hop feature: When an intermediary receives a
   request, the only requirement is that it echoes the token back in any
   resulting response.  There is no requirement or expectation that an
   intermediary passes a client's token on to a server or that an intermediary 
   uses extended token lengths itself when receiving a request with an 
   extended token length.

Note should be taken here that such intermediary can itself be “stateless”, as described in Section 3.1 just below.

In wireless mesh networks,
   where all traffic is visible to a passive attacker, encryption may
   not be needed as the attacker can get the same information from
   analyzing the traffic flows.

I am quite confused by this sentence which seems as an oversimplification. What kind of an attacker are you considering here?

Mališa

> On 26 Jun 2019, at 16:14, Carsten Bormann <[e-mail]> wrote:
> 
> This is a Working Group last call on
> 
> https://tools.ietf.org/html/draft-ietf-core-stateless-01
> 
> The WGLC will end in exactly 336 hours so we can discuss the outcome at the CoRE WG Interim meeting on 2019-07–10.  Please indicate your position in a message to the CoRE mailing list ([e-mail]) or, exceptionally, to the chairs ([e-mail]).
> 
> Please find my chair’s review below; I believe the items raised there can be discussed during the WGLC alongside the concerns of other WG members.
> 
> Grüße, Carsten
> 
> 
> Chair’s review of draft-ietf-core-stateless-01
> 
> # Major
> 
> Discovery is currently focused on whether the server supports extended token lengths at all.  Given that the maximum extended token is rather large for a constrained environment, the client may be interested to find out how large tokens can be for this server.  With CSM, this would be trivial (change empty option value to an uint value).  With trial-and-error, this leaves the client with binary search (probably along the lines of the token sizes it actually can make use of).
> 
> # Minor
> 
> Section 3.3 suddenly starts to talk about authentication tags and freshness indicators; this might require additional explanation (in particular since there are BCP 14 keywords in these paragraphs).  Section 4.2.1 has some implementation guidelines that could possibly be expanded to cover this.
> 
> 
> 
> 
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core