Re: [core] Genart last call review of draft-ietf-core-stateless-05

Dan Romascanu <> Wed, 01 April 2020 15:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 541B23A11B4; Wed, 1 Apr 2020 08:28:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id woyGKapPe86N; Wed, 1 Apr 2020 08:28:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 100E03A114F; Wed, 1 Apr 2020 08:28:36 -0700 (PDT)
Received: by with SMTP id y14so3415iol.12; Wed, 01 Apr 2020 08:28:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OPE5UHrkWQsJp+Du7l9lFOslq380bP/z7XjMa1+sCF0=; b=lzhPW4coxe6U8j/7UeiktHNL+Eu5qlM+0/ycTuz45V0E5oyonbrpymb558RLWxx/D9 4F7UfStUaz0pNdQeNawJepEGnWOmaa7bSHKwJ7Nd/oR4WuPeZLG9yB/AuhOxknF0hWFe bOKMv6f9C/WMSKEEn2MkCCSqo/OlLUhbuky50GBFJpR4Hu+Xqgkssd8SIqBUPfd/7r9b SDLy1Zbs7fboO4rzZg+L/0p5S+p+Lc9/ECBRzY5ZjNbKSvkN3JMHvbaRxFBVwgveR5H5 1yBK+Pf95In4KdIDY1CmllaD6zt8snncI1Jf44jvnhK+8nmXEoBjE8MGUW37G5+LQDv2 APSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OPE5UHrkWQsJp+Du7l9lFOslq380bP/z7XjMa1+sCF0=; b=kLXF23BC/HBNSqJpQWKDaOaWKoIooC4ehWPv+o/5IlD+SupQwuDh9DR49f0YOqPkdi xlJtTDliwSUpvpY+LBmzSwH5VipdWxDnKji8Xpik+JWEfuzPv0prFMGZz6D0o2npRA0I /I8ESIB27HO565piJaC7Qr0DCg1mATzexq+IniNqZwpE0VZgKmvNRm04kBbmJ7NymYAO 4Us357k5ZuRzBQ/WsW/adjILaoNYg3s6Snz1Cty1hmZwP+xx3NHnBbdCUClsedW3wWQP 7u97crhSlsN5pfZ6xVeLadbpJtoB9aEt60tlpkMOKSUoRWR7Rm7v6Wtj4v0RP3JFlwei D47A==
X-Gm-Message-State: ANhLgQ2DgAJxL6brFdkb1Yt4FH4v6R/HerLSvnJt47HJ0YRRsj9nVeX9 TLtaxH6BaNI3IhV/lnX285qi+Mlqt3OsVyn59aI=
X-Google-Smtp-Source: ADFU+vsfjKvkPf6GA0ZfB3HRAGnxMXS0UZkVU1V94Zmu37EhjkGpwVMcCVflbLF3AJUn8DPzKHPhccrI9f7a7fXman0=
X-Received: by 2002:a02:634e:: with SMTP id j75mr21186576jac.23.1585754914937; Wed, 01 Apr 2020 08:28:34 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Dan Romascanu <>
Date: Wed, 01 Apr 2020 18:28:22 +0300
Message-ID: <>
To: Klaus Hartke <>
Cc: "" <>, "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000067e1b505a23c564e"
Archived-At: <>
Subject: Re: [core] Genart last call review of draft-ietf-core-stateless-05
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: Wed, 01 Apr 2020 15:28:41 -0000

Hi Klaus,

Thanks for your quick reply and for addressing the issues raised in my

See below my short comments on a couple of issues.



On Wed, Apr 1, 2020 at 1:27 PM Klaus Hartke <>

> Dan Romascanu wrote:
> > This is a very clear and well-written document. I have a few minor
> issues that
> > I suggest to clarify before approval and publication.
> Many thanks for your review!
> > 1. It would be useful to include some considerations whether the authors
> > consider useful / possible / allowed that the mechanism (extended token
> > lengths) presented in this document can be used for other purposed than
> > the by-design the use case (avoiding per-request state).
> The last paragraph in Section 1 says:
>    While the use case (avoiding per-request state) and the mechanism
>    (extended token lengths) presented in this document are closely
>    related, both can be used independently of each other: Some
>    implementations may be able to fit their state in just 8 bytes; some
>    implementations may have other use cases for extended token lengths.
> Does that solve your issue?

Actually this is exactly the paragraph that triggered my concern. Does
'using independently' mean that you encourage or do not care
implementations in the future dealing with other use cases? If the answer
is yes, maybe the current text is fine. If the answer is 'rather not' than
a discussion would be welcome.


> > 3. In Section 5.2:
> >
> > > The use of encryption, integrity protection, and replay protection of
> >    serialized state is recommended in general, unless a careful analysis
> >    of any potential attacks to security and privacy is performed.  AES-
> >    CCM with a 64 bit tag is recommended, combined with a sequence number
> >    and a replay window.  Where encryption is not needed, HMAC-SHA-256,
> >    combined with a sequence number and a replay window, may be used.
> >
> > A few issues with this paragraph. Why are not 'recommended' and 'may'
> > capitalized? The formulation 'is recommended in general' seems odd, and
> > the rest of the sentence does not clarify. What does 'a careful analysis
> of any
> > potential attacks' mean? Who is supposed to perform this analysis and who
> > can ensure it is 'careful enough' at any given point in time for any
> potential
> > attacks?
> AFAIK, the Security Considerations section is supposed to discuss
> security-related issues that users need to be aware of, but not make
> normative statements. So all the normative requirements are in Section 3.1.
> (Where 'users' in this case are implementations and specifications that
> decide to make use of this implementation strategy in clients.)
> Overall, it's a bit difficult to make normative requirements here, because
> these are usually about the interoperability e.g. of a client and a server.
> But in this case, the client only needs to interoperate with itself (it
> needs to accept a token that it created itself) and the only real
> requirement is that "client implementations MUST NOT be vulnerable to
> maliciously crafted tokens". The meaning of "vulnerable" and "malicious"
> here depends a lot on the application/deployment-specific context; the
> document can really just highlight some potential issues that users should
> take into consideration.
> I'm open to concrete suggestions for text improvements, though.

I believe that I understood the point that you are making. If I am to
suggest text improvements, I would:

- s/recommended in general/recommended/
- clarify, maybe in this very words that "the requirement is that client
implementations must not be vulnerable to maliciously crafted tokens"