Re: [core] draft-hartke-core-stateless

Klaus Hartke <> Tue, 18 September 2018 08:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7445F130E93 for <>; Tue, 18 Sep 2018 01:31:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pngPgfm22OOK for <>; Tue, 18 Sep 2018 01:31:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DBDE8127133 for <>; Tue, 18 Sep 2018 01:31:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailgw201801; c=relaxed/simple; q=dns/txt;; t=1537259514; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kqrzXibeIg/uhKm3JlXyrUv390xMnH8GvMF9FBGJou4=; b=IVm5DeDR55w94L20wbWsC1sQ1ePstNgsQIl0jwwIuih6uFdUOYzbatG74aSvw2gp ZWUsfAKxVd4JeB2t/RJwDqpsjO7042MAsL4Al6d+4+amCIxG8Z+dbuU4JfmcCMhb i132P3JPKNrX68h90RLXdz+3wqc8tCHo/W20FKrKRkU=;
X-AuditID: c1b4fb25-cd2929c0000013ad-90-5ba0b7face40
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 5C.D1.05037.AF7B0AB5; Tue, 18 Sep 2018 10:31:54 +0200 (CEST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 18 Sep 2018 10:31:54 +0200
Received: from ([]) by ([]) with mapi id 15.01.1466.003; Tue, 18 Sep 2018 10:31:53 +0200
From: Klaus Hartke <>
To: Jim Schaad <>, "" <>
CC: 'Core' <>
Thread-Topic: draft-hartke-core-stateless
Thread-Index: AdRJSZxEFVxiHpnJRYejIUsSOODSiwF3q0uw
Date: Tue, 18 Sep 2018 08:31:53 +0000
Message-ID: <>
References: <009901d4495b$194c4f30$4be4ed90$>
In-Reply-To: <009901d4495b$194c4f30$4be4ed90$>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbG9TPfX9gXRBtdPiljse7ue2aJz+VJm i9XTv7M5MHtsnDOdzWPJkp9MAUxRXDYpqTmZZalF+nYJXBk/Z+1hK9ijUnH00A+mBsYjyl2M nBwSAiYSZw7MY+9i5OIQEjjKKLF++SU2COcbo0Tj3v3MIFVCAssYJeaergGx2QT0JFZN/cEO YosIVEhsvb6DBcRmFpCS6Dl5mAnEFhbQlLi2cgMTRI2WxKy9y6HqjSRe/zoCVs8ioCpxsuk6 WA2vgLXEgbZbULvsJVbPmMgGYnMKOEj0NO8EizMKiEl8P7WGCWKXuMStJ/OZID4QkFiy5zwz hC0q8fLxP1YIW0li77HrQLs4gOo1Jdbv0odoVZSY0v2QHWKtoMTJmU9YJjCKzUIydRZCxywk HbOQdCxgZFnFKFqcWpyUm25krJdalJlcXJyfp5eXWrKJERhHB7f8Vt3BePmN4yFGAQ5GJR5e rWULooVYE8uKK3MPMUpwMCuJ8HLmAIV4UxIrq1KL8uOLSnNSiw8xSnOwKInzPjTfHCUkkJ5Y kpqdmlqQWgSTZeLglGpgbGwTLzq4qb7p348+2Y2rZWcEaV1X27tHau/uWT8t23+cS286tMLr audLzc+uq18z5L6SFd4dulBtmUvEreXREjMf3O27PudZzyqJiCf8tu+sXJcGZF7+YxF1WNfC 5KHsi/tdvxOz1aZEW28+06yY2aZmIsxn8PiXQcOZGNWrM/5mfrxzZYrDNCWW4oxEQy3mouJE AFi0O5yfAgAA
Archived-At: <>
Subject: Re: [core] draft-hartke-core-stateless
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: Tue, 18 Sep 2018 08:31:58 -0000

Hi Jim,

thanks for the thorough review! I've just submitted revision -01 with some clarifications.

> Section 2.2.2 - Depending on circumstances, I think you might get a Gateway
> time out error response as well for some types of proxies.

Could you give an example? To me it seems that a message format error or unsupported critical unsafe-to-forward option will reliably give a Reset message or Bad Option response from the next hop.

> Section 2.2.2 - Should there be a special indicator that a server cannot deal
> with tokens of longer than n bytes?  Otherwise this would seem to be a good
> way to exhaust resources on the server/proxy.

This is a very good question and a point that needs discussion in the WG. We could mandate a fixed upper limit that all implementations of the draft must support, or try to come up with some maximum length token detection/negotiation.

> Section 3.1 - I would think that repeatable would be better for the option as
> then multiple proxies could just insert a new option rather than attempting
> to extend or wrap the current value.
> Section 3.1 - I am not sure that I agree that the option should be unsafe to
> forward.  As long as a client and a server agree to deal with the option then it
> does not matter what any intermediate proxies might do.  Changing this
> modifies 3.2.2 as well
> Section 3.1 - above two arguments would change the values of critical as well.
> I still think that it would be part of the cache key for a proxy that did not
> understand the option, it might be noted that a proxy which understands the
> option would be in its right to exclude the option from computing the cache
> key.
> Section 3.1 - The last sentence may need to have some additional text added
> about the length of the Token field when splitting the value.  Also needs to
> have a note about the interactions messages in those cases where the
> portion placed in the token field does not change.  This seems quite possible
> if one uses a prefix.

I'm skipping these points as Section 3/Variant B is removed in revision -01.

> Section 4 - What happens for interactions w/ the observe option?
> Section 4.1 - I don't see how paragraph 3 follows from the use of this option.
> This is merely a true statement for all intermediaries that don't bother
> caching.  Note that if the intermediary does cache responses, but does not
> cache this option then the entire paragraph does not seem to be correct.  It
> could respond from the cache, but not worry about keeping this value in the
> cache and trying to figure out when and how to ignore.

Good observation. I've rephrased this part in revision -01. Could you take a look?

> Security Considerations - Need additional text someplace about swapping of
> tokens which might be more consequential than would normally be the case.

Text contributions to the draft are highly welcome :)

> Someplace - Interactions between OSCORE and this new option.

I don't think there are any interactions with OSCORE.

> Freshness indicator may need to be dealt with on a per server basis or using
> the same type of window that DTLS uses.  If a client sends out two different
> messages to two different servers, the order of responses should not control
> if a response is processed.

Text contributions to the draft are highly welcome :)