Re: [core] Review of draft-hartke-core-stateless-01

Klaus Hartke <> Thu, 11 October 2018 12:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B220130E5A for <>; Thu, 11 Oct 2018 05:28:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FTyjtB_B_-in for <>; Thu, 11 Oct 2018 05:28:45 -0700 (PDT)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E4C7D130E48 for <>; Thu, 11 Oct 2018 05:28:44 -0700 (PDT)
Received: from ([]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gAa55-0002XY-Fp; Thu, 11 Oct 2018 14:28:43 +0200
Received: by with SMTP id 23-v6so5251213qkh.8 for <>; Thu, 11 Oct 2018 05:28:43 -0700 (PDT)
X-Gm-Message-State: ABuFfojb/sIiNiK7de54ZBaZwyjWlL7fjEjzqlRxjmYHjiLEW/yQ/5VG P0G6mZCZjNMFeI5YSZbvQja/9U/gAZnNhENc7WU=
X-Google-Smtp-Source: ACcGV61b7jVKuxWenvknRM+IrPuizqbh3BrCoq2Ds5u5YebGDzOxDf9kTGD3m2uB+YfZCD0iBjSi/IF3klLpu57DtjY=
X-Received: by 2002:ae9:d801:: with SMTP id u1-v6mr1085844qkf.291.1539260922428; Thu, 11 Oct 2018 05:28:42 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Klaus Hartke <>
Date: Thu, 11 Oct 2018 14:28:06 +0200
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: John Mattsson <>
Cc: " WG" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-bounce-key:;; 1539260924; aa758f9c;
X-HE-SMSGID: 1gAa55-0002XY-Fp
Archived-At: <>
Subject: Re: [core] Review of draft-hartke-core-stateless-01
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Oct 2018 12:28:47 -0000

Hi John,

thanks a lot for the review!

John Mattsson wrote:
> - Should maybe mention that part of the state can be serialized, i.e. something between figure 1 and figure 2

Added between figure 1 and figure 2.

> - The mechanism (extended token) and the use case (stateless client) are very entangled. I think it would be good to separate them a little bit more. Some implementations may fit their state in 8 bytes. And maybe some future applications have other use cases for extended token.

Added at the end of section 1:

   While the mechanism (extended token lengths) and the use case
   (stateless clients) presented in this document are closely related,
   both can be used independently of the other: Some implementations may
   fit their state in 8 bytes; some implementations may have other use
   cases for extended token lengths.

> - Section 3 talks about integrity protection and freshness.

I thought the term "freshness" would imply that. Could you provide
some text to clarify the paragraph?

> - The mechanism can be used to fill the available memory of a proxy, causing DoS, this should be mentioned in the security considerations. I think the draft should also say which Token lengths an implementation supporting this draft needs to support: 65804 bytes or something smaller? Up to the implementation?

The idea in the interim call yesterday was along the lines of: A node
in client role needs to support token lengths up to the maximum length
of the tokens it sends; the supported token length for a node in
server role is up to the implementation. If the serialized state fits
in this implementation limit, it works; otherwise, there's probably
not much the node in client role can do anyway to make the state
smaller, so it fails.

Should there be a mandatory-to-implement minimum length, e.g., 24 bytes?

I think there needs to be a requirement that the node in server cannot
change its maximum supported length at will (e.g., when it runs out of
memory), because that would make discovery of support unreliable.

> - The TODO security considerations should talk about privacy and pervasive monitoring. When used by a proxy, the draft need to discuss that the mechanism may make information (like client IP) available on paths where the information was not available before. If used by a non-proxy client without encryption if can reveal a lot of privacy sensitive information that would otherwise be encrypted.

Contributions are welcome!

> - I think the encryption requirement (MAY) is too weak. Is there a reason not to encrypt at the same time as integrity protection is done? The encryption requirements should maybe be different for proxy clients and non-proxy clients.


More seriously: Since this is not an interoperability issue, I'm not
sure how much we can require here in general. More input on this would
be great.

> - I think the draft should give developers some recommendation regarding cryptographic algorithms.

This is not an interoperability issue. But giving some implementation
guidance might be helpful indeed. What algorithm should be