Subject: [core] I-D Action: draft-ietf-core-stateless-02.txt

From: [email-masked]
Date: Mon, 21 Oct 2019 10:26:53 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Constrained RESTful Environments WG of the IETF.

        Title           : Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)
        Author          : Klaus Hartke
	Filename        : draft-ietf-core-stateless-02.txt
	Pages           : 17
	Date            : 2019-10-21

Abstract:
   This document provides considerations for alleviating CoAP clients
   and intermediaries of keeping per-request state.  To facilitate this,
   this document additionally introduces a new, optional CoAP protocol
   extension for extended token lengths.

   This document updates RFCs 7252 and 8323.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-stateless/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-core-stateless-02
https://datatracker.ietf.org/doc/html/draft-ietf-core-stateless-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-stateless-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 21 Oct 2019 19:31:14 +0200

Hej!

I've just submitted -02 of draft-ietf-core-stateless. This revision
intends to address all feedback received during WGLC.

@Reviewers: It would be great if you could verify that your WGLC
comments have been resolved.

Klaus

On Mon, 21 Oct 2019 at 19:27, <[email-masked]> wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 22 Oct 2019 09:08:31 +0000

Hi Klaus,

> comments have been resolved.

Yes, the changes in -02 address my previous comments, thanks!

Content-wise, I think the document is ready to move forward.

I've left a bunch of random editorial comments below.  Take a look and
see if you agree.

Cheers, t

=-=-=-=

   Section 3 of this document provides considerations clients opting
   into becoming "stateless" in this way.

This sentence doesn't parse right; it looks like it's missing a "for"
just before "clients"?

   The maximum token length that sender and
   recipient implementations support may be more limited

s/more limited/shorter/

  The active value of the Extended-Token-Length Option is replaced each
  time the option is sent with a modified value.

s/replaced/updated/
s/is sent with a modified value/is received/

  Its starting value is its base value

The starting value is the Option's base value.

  When an option value outside this range is received, the value MUST be
  clamped to be within this range.

I find this sentence slightly difficult to action: it doesn't say which
value should the receiver pick in case of {over,under}flow -- is it one
of RANGE_MAX / RANGE_MIN (whatever the closest) or some arbitrary value
within [RANGE_MIN, RANGE_MAX] ?  A bit more clarity would help.
Tangentially, I don't see a good reason why the receiver should silently
accept out-of-range values from the peer?  I appreciate that the
effective TKL is constrained anyway, but my preference would be to fail
with an explicit signal.

  to indicate the maximum length of a token in bytes that it accepts in
  requests.

Maybe: "to indicate the maximum acceptable length of the token (in bytes)"

  support by a server does not oblige a client to actually make use of
  token lengths greater than 8.

s/oblige/force/

  AES-CCM with a 64 bit tag is recommended

CCM (and the tag choice) looks fine given that a) we need to buffer the
whole header anyway, and b) we want to limit the amount of tag bits as
much as possible while keeping the whole auth-enc machinery secure.
Maybe we should stick the usual note about nonce reuse / misuse
(especially for clients with low-quality entropy sources) and key
rotation strategies (since proxies potentially need to route a
considerable amount of messages).

  Discovery needs to be performed for each pair of hops.

s/each pair of hops/each hop/

   If a server supports extended token lengths but receives a request
   with a token of a length it is unwilling or unable to handle, it MUST
   NOT reject the message.  Instead, it SHOULD return a 5.03 (Service
   Unavailable) response.  (Returning this response requires that the
   server implementation is able to return a token of any length, even
   if it otherwise cannot handle tokens of that length.)

This para is a tad dense.  In particular, the use of "unable" seems to
contradict the MUST NOT: if I'm unable to handle this how can I not
reject it, what should I do?  I'm probably not up-to-speed with the
related discussion, but I don't understand why we moved from 4.xx to
5.xx?

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 22 Oct 2019 12:09:51 +0200

Hi Thomas,

thanks a lot for your review!

> This sentence doesn't parse right; it looks like it's missing a "for"

Fixed.

>    recipient implementations support may be more limited

Done.

> The starting value is the Option's base value.

This wording is copied from https://tools.ietf.org/html/rfc8323#section-5.3.1

> within [RANGE_MIN, RANGE_MAX] ?  A bit more clarity would help.

The intention was to say: If the value is less than 8, then it shall
be set to 8. If it's greater than 65804, then it shall be set to
65804. I though that's what clamping means, no?

> effective TKL is constrained anyway, but my preference would be to fail

The rationale is different for the two cases:

If the server indicates it can handle tokens up to 5 MiB, then the
client cannot send a 5 MiB token, because the maximum length supported
by the message format is 65804. But if a server can handle tokens up
to 5 MiB, then it clearly also can handle tokens up to 65804 bytes,
right? So there's not really an error if a server indicates a value
greater than what can actually be sent.

If the server can only handle tokens of some length that is less than
8 bytes, then it's clearly not implementing RFCs 7252 and 8323
correctly. This will never happen, so I think a client implementation
shouldn't bother spending any more cycles than on a comparison and a
conditional move.

> Maybe: "to indicate the maximum acceptable length of the token (in bytes)"

Maybe this?

    A server can use the elective Extended-Token-Length Capability
    Option to indicate the maximum token length it can accept in
    requests.

>   token lengths greater than 8.

This wording is copied from https://tools.ietf.org/html/rfc8323#section-5.3.2

> considerable amount of messages).

Would you like to propose some text?

> s/each pair of hops/each hop/

Done.

> reject it, what should I do?

Handling a request usually goes through multiple steps from receiving
the message to handing it over to application logic. The intention
here was to say that a server implementing the document at least needs
to support large tokens in the first few steps (enough to return an
error response rather than a Reset message -- which is how we
distinguish between "server does not support extended tokens" and
"server temporarily does not have enough memory for this extended
token").

> I'm probably not up-to-speed with the

Now that you're mentioning it... It seems this needs a bit more thinking.

There's the case where the server temporarily doesn't have enough
memory to handle a request with a large token (so nothing that the
client can do about -> 5.xx). And there's the case where the client
chose a large token that the server will never be able to handle after
the initial steps (so not something the client should try again ->
4.xx? 5.xx?).

What do you think?

Klaus

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 22 Oct 2019 10:33:22 +0000

Hi Klaus,

> 65804. I though that's what clamping means, no?

Sure, it's not "clamp" but the following "to be *within* this range"
that creates the ambiguity.

> shouldn't bother spending any more cycles than on a comparison and a

OK, thanks for the rationale.  I can surely live with that.

>     Option to indicate the maximum token length it can accept in

LGTM

> This wording is copied from https://tools.ietf.org/html/rfc8323#section-5.3.2

OK, it sounded slightly unfamiliar to me, but a) I'm not a native speaker,
b) if the RFC Editor is happy with that construction who am I to argue? :-)

> Would you like to propose some text?

Sure, will do on Github.

> "server temporarily does not have enough memory for this extended

Thanks.  This is exactly what I meant by "dense": it looks like there is
an interesting amount of relevant information that is left implicit.  I
think articulating the assumptions as you just did will make it easier
on future readers.

> the initial steps (so not something the client should try again ->

The latter looks like a 4.xx to me.

Cheers, t

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 22 Oct 2019 13:07:21 +0200

> that creates the ambiguity.

So maybe just this?

            The option value MUST NOT be less than 8 or greater than 65804. When
            an option value outside this range is received, the value MUST be
            clamped to this range.

(I'm not a native speaker; help is appreciated.)

> [...]

Like so?

   If a server supports extended token lengths but receives a request
   with a token of a length it is unwilling or unable to handle, it MUST
   NOT reject the message, as that would imply that extended token
   lengths are not supported at all.  Instead, if the condition is
   temporary, it SHOULD return a 5.03 (Service Unavailable) response.
   If the condition is permanent, it SHOULD return a 4.00 (Bad Request)
   response.

   Design Note:  The requirement to return an error response when a
      request cannot be handled might seem somewhat contradictory.
      However, handling a request usually involves a number of steps
      from receiving the message to handing it over to application
      logic.  The idea is that a server implementing this document at
      least should support large tokens in the first few steps (enough
      to return an error response rather than a Reset message).

Klaus

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 22 Oct 2019 12:00:39 +0000

Hi Klaus,

On 22/10/2019, 12:08, "Klaus Hartke" <[email-masked]> wrote:
>             The option value MUST NOT be less than 8 or greater than
>             65804.  When an option value outside this range is
>             received, the value MUST be clamped to this range.
>

The poor soul version:

The option value MUST NOT be less than 8 or greater than 65804.  If
the received option has a value greater than 65804, then it MUST be
set to 65804.  If the received option has a value less than 8,
then it MUST be set to 8.

>    If the condition is permanent,

     such as when the client is sending a large token that the server
     will never be able to handle,

>    it SHOULD return a 4.00 (Bad Request)
>    response.
>

Looks great, thanks.

Cheers, t

PS: I couldn't find the Github repo, so I'm sticking here what I'd have
    written there:

Unfortunately, it is easy to misuse counter mode.  If counter block
values are ever used for more than one encryption operation with the
same key then the same key stream will be used to encrypt both
plaintexts and the confidentiality guarantees are voided. Devices with
low-entropy sources -- as is typical with constrained devices, which
incidentally happen to be a natural candidate for the stateless
mechanism described in this document -- need to carefully pick a nonce
generation mechanism that provides the above uniqueness guarantee.
Besides, since it can be extremely difficult to use AES-CCM securely
when using statically configured keys, implementations SHOULD use
automated key management [BCP107].

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 22 Oct 2019 15:57:26 +0200

> then it MUST be set to 8.

Protocols 101 doesn’t like that.  Reinterpreting values outside the currently defined range as something else means that you never get to use these numbers again.  (Imagine we had done this with the old TKL in RFC 7252.)

What was wrong with rejecting bad numbers?

Grüße, Carsten

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 22 Oct 2019 14:45:59 +0000

> What was wrong with rejecting bad numbers?

I had the same question downthread, to which Klaus replied with an
optimisation argument.