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

From: [email-masked]
Date: Tue, 29 Oct 2019 11:46:11 -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-03.txt
	Pages           : 18
	Date            : 2019-10-29

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-03
https://datatracker.ietf.org/doc/html/draft-ietf-core-stateless-03

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

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: Carsten Bormann <[email-masked]>
Date: Wed, 30 Oct 2019 16:41:12 +0100

> 	Filename        : draft-ietf-core-stateless-03.txt

Thank you, Klaus.

While I haven’t completed by chair’s review of the new version yet, one issue stands out, as it cannot really be solved beautifully, and it is hard to give advice that properly covers all the situations.

   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 server cannot
   handle the request at the time, it SHOULD return a 5.03 (Service
   Unavailable) response; if the server will never be able to handle
   (e.g., because the token is too large), it SHOULD return a 4.00 (Bad
   Request) response.

(…followed by a few design notes that are useful to read.)

The situation that may not be properly covered here is a constrained server that doesn’t have resources to handle a full-size IP packet, e.g. for performing outward adaptation layer fragmentation of the response.

So far, we haven’t really had a “you must be this tall to play” on CoAP, and that includes message size.  We do have recommendations (1152 bytes, Section 4.6 of RFC 7252), but these are more for guiding a client.  A server might have resources that genuine never need large requests, and it has control over the response size (e.g., using block-wise where needed).  With an incoming token of essentially unlimited length (dreaming up a random limit doesn’t help, either), this situation changes.

So what can a constrained server that is limited to, say, 256-byte packets, do?

* It can reject all extended token lengths.  Safe, but makes it less useful for stateless proxying.

* It can accept, say, extended token lengths up to 37 bytes.  Great.  Now, the above means:

If a client sends a request with a 999 byte token, the server

* cannot send a response, because that would need to copy the full token

* cannot send a Reject, because that has a MUST NOT in the text above

So it seems the current text requires it to remain silent.  That sure works, and is easy to implement, but makes for a slow and wasteful discovery process.

Grüße, Carsten

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 30 Oct 2019 21:53:18 +0000

Hi Klaus,

> https://www.ietf.org/rfcdiff?url2=draft-ietf-core-stateless-03

I reviewed your latest changes and they all look good to me.

Thank you for addressing my last batch of comments, I have none left.

I also want to say that I agree with the conclusion we reached at
today's interim regarding Carsten's point [1]. There's nothing that we
can add to the current text that'd make things sensibly better.

Ship it! :-)
t

[1] https://mailarchive.ietf.org/arch/msg/core/JD18p4SrVxQhzcplEoYOZokb1d4

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: Carsten Bormann <[email-masked]>
Date: Thu, 31 Oct 2019 18:08:30 +0100

I did a review of draft-ietf-core-stateless-03.txt, with non-trivial results below.
(Editorial nits went directly to the author.)

I haven’t independently verified that all reviewers’ comments were addressed but will do this before we ship to the IESG what likely will be -04.

Grüße, Carsten

## Minor

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

I am still not a fan of re-interpreting disallowed values.
(Assuming there was later any reason to go beyond 65804, of course allowing
larger values and interpreting these as 65804 because a client knowing
just this specification cannot make use of lengths >65804 makes sense.
Not so sure about the values 0..7 though.)

           have been forwarded by an intermediary.  To ensure that this does not
           lead to inconsistent resource state, a stateless intermediary MUST
           include the Request-Tag Option [I-D.ietf-core-echo-request-tag] in
           block-wise transfers with a value that uniquely identifies the client
           in the intermediary's namespace.

-> To ensure that this does not lead to inconsistent resource state, a
stateless intermediary that wants to forward requests with Block1
options will need to also include a distinguishing option such as the Request-Tag Option
[I-D.ietf-core-echo-request-tag] in a way that uniquely...

           When using AES-CCM, repeated use of the same nonce under the same key

Not just AES-CCM, just about any AEAD.  Maybe say: When using an
encryption mode that depends on a nonce, such as AES-CCM, ...

## Nits

           A client SHOULD NOT assume that extended token lengths are supported
           by a server 60 minutes after receiving a response with an extended
           token length, as network addresses may change.

s/60/later than 60/

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 31 Oct 2019 22:19:24 +0000

On 31/10/2019, 17:08, "core on behalf of Carsten Bormann" <[email-masked] on behalf of [email-masked]> wrote:
> Not just AES-CCM, just about any AEAD.

The problem is not with AEAD per se, we could have picked GCM-SIV and
there would have been no trouble.  The problem is with the underlying
CTR.

Quibbles aside, the document recommends CCM -- over other AEAD
constructions -- and does so consciously, I think, to provide the best
trade-off between overall security, wire efficiency and processing cost.

This point does not surface in the current text, but the recommendation
for CCM is actually quite precise, and maybe worth an upper-case
RECOMMENDED?

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 1 Nov 2019 07:44:15 +0100

Hi Thomas,

thank you again for all your great input on this draft.

> On Oct 31, 2019, at 23:19, Thomas Fossati <[email-masked]> wrote:
> 

Right, that’s why my proposed text specifically talks about “encryption mode that depends on a nonce”.

> for CCM is actually quite precise, and maybe worth an upper-case

I agree that this is a good recommendation.  It is not an interoperability requirement, though (and 64 bits of authenticator may actually be a bit low for some applications), so the purist in me isn’t thrilled about using a BCP 14 keyword.

Grüße, Carsten