Re: [Tsv-art] Tsvart last call review of draft-ietf-core-echo-request-tag-11

"Christian M. Amsüss" <christian@amsuess.com> Wed, 09 December 2020 15:09 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719983A0DFF; Wed, 9 Dec 2020 07:09:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Y83_ILhuDrnV; Wed, 9 Dec 2020 07:09:06 -0800 (PST)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81E083A0DEA; Wed, 9 Dec 2020 07:09:04 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id D85324060D; Wed, 9 Dec 2020 16:09:02 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 176ABAB; Wed, 9 Dec 2020 16:09:01 +0100 (CET)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:c33c:d942:e648:1b58]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id BD4E2121; Wed, 9 Dec 2020 16:09:00 +0100 (CET)
Received: (nullmailer pid 3046429 invoked by uid 1000); Wed, 09 Dec 2020 15:09:00 -0000
Date: Wed, 09 Dec 2020 16:09:00 +0100
From: "Christian M. Amsüss" <christian@amsuess.com>
To: Joerg Ott <jo@acm.org>
Cc: tsv-art@ietf.org, draft-ietf-core-echo-request-tag.all@ietf.org, last-call@ietf.org, core@ietf.org
Message-ID: <X9DojFWbrAWXVTPS@hephaistos.amsuess.com>
References: <160686064132.16683.9970897893331887294@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="HLmHlRRi8kfC71p2"
Content-Disposition: inline
In-Reply-To: <160686064132.16683.9970897893331887294@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/KXf-PlSqkYrQHL0u9wLXkLrQFeY>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-core-echo-request-tag-11
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Dec 2020 15:09:09 -0000

Hello Jörg,

Thank you for your review and your comments.

> One question that arises is why these three quite distinct mechanisms fixing
> different parts of the RFC 7252 are compiled into a single document. Efficiency,
> yes, but otherwise, they don't seem to have much in common.

The mechanisms also share common patterns in the attacks they prevent,
and playing through scenarios of one mechsnism led to a better
understanding of the others. It is hoped that the reader can use the
mind set built up understanding the necessity for one mechanism leads to
a better one on the others.

> A question out of curiosity: in section 3.4, could a client easily exhaust server
> resources if just sent many blocks and changed the Request-Tag on each of them?

No more than it can by addressing them to different resources (where the
query parameter is part of the underlying identity) -- or even any
made-up uncritical safe-to-forward option. CoAP servers that perform
atomic processing typically have limited slots for these operations
(either global, per resource or per client), and any later request
invalidates the former's state.

> Should sections 3.6 and 3.7 move to an appendix? They discuss design alternatives.

Question for these came up so frequently in discussions around the
document that I think it's better here where it's visible.

Happy to move it over if you or other commenters insist, but that should
happen in awareness of the underlying questions' occurrence.

> The last sentence in the second to last paragraph of section 1.1 has nested brackets,
> which may or may not be intentional.

It's an unintentional occurrence which I'd -- now aware -- also make
consciously to avoid extra prose that'd set aside the defining terms
from the accompanying remarks.


The remaining nits have been addressed in the editors' copy, and will be
part of the next version.

Thanks again
Christian

-- 
You don't become great by trying to be great. You become great by
wanting to do something, and then doing it so hard that you become great
in the process.
  -- Marie Curie (as quoted by Randall Munroe)