Re: [core] Genart last call review of draft-ietf-core-stateless-05
Dan Romascanu <dromasca@gmail.com> Sun, 12 April 2020 10:11 UTC
Return-Path: <dromasca@gmail.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C163A2047; Sun, 12 Apr 2020 03:11:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQO8AXe6PGP4; Sun, 12 Apr 2020 03:11:52 -0700 (PDT)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F6B3A2046; Sun, 12 Apr 2020 03:11:52 -0700 (PDT)
Received: by mail-io1-xd29.google.com with SMTP id o127so6547430iof.0; Sun, 12 Apr 2020 03:11:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q0cOC0rhlITKX8ksqNwamA3vM0yCqKMvxfA0OrpMpUE=; b=kOGoA+/E6f8fvLsAWp0cLL3UFt8QnuDUBMZIYqR8eLVIDfcZIUSq/XRzqp7xtRW0LB x+7v3k79dip7fUryhYba0HPExWqURUE5RazbU//2gAb28dI2GdUUmDveE7RtOYuNqFQ4 YGy5MOKvdhfJFRI2ex6gws0+iet9qTAus0gElTIyHGwpto+ze+t6O1G+fz30nddehPnT Mwb2z1dpTvhQDx3vA9X6Nu+qMh6L/DNbnGdIG/ZiYyNhBa1S5qL1VIR6a0i9eBn39vPT 1hWOPt0PVAyrWLcZ6eL2yjc+RbGpj+7HkgjFPryKgqGDe51k1YBkmLjAsO7H/V2BC4HU RQzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q0cOC0rhlITKX8ksqNwamA3vM0yCqKMvxfA0OrpMpUE=; b=DGtVy8X36UvE5xE23wHYNXBsHubc9EEUt6QNo5IXb/IeyGnsFDztuuUuRnesmTLlT1 eKb7HKngjQRw8he3/l58DYNx3O2P8PjKaMx27azIpnUHFahFEGsCknUV8PoCdXldCdWz Xl7xBh6YI75wuUV1o2XbPqRVzA7k+iI3pt7lcZm9OxhSdWgdCyzIhg9X24inAzowtMH5 WMmZCC2Lh0oESnz87L6ceolZOa8DOmO2TJnWy8CqqmKPgDa0Yl5B0TOVFcXDU6vhx/0e azDH6z6yI29pgwFsfceryomUlrfA4e8X2HuQhq0JzFcnEaQd+VPHVLRLX5Lb0rY8qf8Y 1grw==
X-Gm-Message-State: AGi0PubGXodm+YfoaDHXe4JFz/od6qsFy7ueEhKX33jU5nYoa0k6Y73F RYeHVVIMcLLkjpk6hUIX8eEzqBdNsksKi4BkOYJUUQ==
X-Google-Smtp-Source: APiQypIFVkx4eiynVwSlapOZaB2Asyn0FYWQEC9Oq5DcEUd/3k5uB/2TFHL4WGW8sfm2oM2XTflWmYcLx9tdbdDcKvQ=
X-Received: by 2002:a02:aa93:: with SMTP id u19mr11633921jai.70.1586686311067; Sun, 12 Apr 2020 03:11:51 -0700 (PDT)
MIME-Version: 1.0
References: <158573098630.30833.17715509721846547699@ietfa.amsl.com> <HE1PR07MB4346B6585F88A677DAF998E3E6C90@HE1PR07MB4346.eurprd07.prod.outlook.com> <CAFgnS4XTyD7AxwgbyAK9oWw_B+Owi6qCwbLhpSp1vn8LH+Lr2Q@mail.gmail.com> <CAAzbHvYWx394b+1tFpd4Ko6N_MON=93xqUxOSm-0KEY7dMkE8g@mail.gmail.com>
In-Reply-To: <CAAzbHvYWx394b+1tFpd4Ko6N_MON=93xqUxOSm-0KEY7dMkE8g@mail.gmail.com>
From: Dan Romascanu <dromasca@gmail.com>
Date: Sun, 12 Apr 2020 13:11:39 +0300
Message-ID: <CAFgnS4XY3YPo7eBfzfMeyXE_RPLWqE1eOQhQCDf0iky8-z=LAQ@mail.gmail.com>
To: Klaus Hartke <hartke@projectcool.de>
Cc: Klaus Hartke <klaus.hartke@ericsson.com>, "last-call@ietf.org" <last-call@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-core-stateless.all@ietf.org" <draft-ietf-core-stateless.all@ietf.org>, "core@ietf.org" <core@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f0f61005a3153197"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/bjQUA2w3aGFRxktA0BWjs0YJbJY>
Subject: Re: [core] Genart last call review of draft-ietf-core-stateless-05
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Apr 2020 10:11:54 -0000
Looks good to me. Thanks for addressing these points. Regards, Dan On Sun, Apr 12, 2020 at 12:31 PM Klaus Hartke <hartke@projectcool.de> wrote: > Dan Romascanu wrote: > >> > 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. > > The paragraph is intended to give permission that extended token > lengths may be used for other purposes than avoiding per-request > state. Of course, these will need security considerations etc., but > those are out of this document's scope. > > >> > > 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" > > I've made these two changes in the Security Considerations section and > also tried to improve clarity in section 3.1. I will submit a -06 > shortly. > > Thanks! > > Klaus >
- [core] Genart last call review of draft-ietf-core… Dan Romascanu via Datatracker
- Re: [core] Genart last call review of draft-ietf-… Klaus Hartke
- Re: [core] Genart last call review of draft-ietf-… Dan Romascanu
- Re: [core] Genart last call review of draft-ietf-… Klaus Hartke
- Re: [core] Genart last call review of draft-ietf-… Dan Romascanu
- Re: [core] [Gen-art] Genart last call review of d… Alissa Cooper