Re: [core] Roman Danyliw's No Objection on draft-ietf-core-echo-request-tag-12: (with COMMENT)

Christian Amsüss <christian@amsuess.com> Sun, 18 July 2021 20:25 UTC

Return-Path: <christian@amsuess.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 9571D3A0953; Sun, 18 Jul 2021 13:25:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 LTb6wQpDBm-j; Sun, 18 Jul 2021 13:25:29 -0700 (PDT)
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 9E1D03A094E; Sun, 18 Jul 2021 13:25:23 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 6FCDA4010C; Sun, 18 Jul 2021 22:25:20 +0200 (CEST)
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 6C4ECD0; Sun, 18 Jul 2021 22:25:19 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [188.20.219.122]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id DB533148; Sun, 18 Jul 2021 22:25:18 +0200 (CEST)
Received: (nullmailer pid 2667889 invoked by uid 1000); Sun, 18 Jul 2021 20:25:17 -0000
Date: Sun, 18 Jul 2021 22:25:17 +0200
From: Christian =?iso-8859-1?Q?Ams=FCss?= <christian@amsuess.com>
To: Roman Danyliw <rdd@cert.org>
Cc: The IESG <iesg@ietf.org>, core-chairs@ietf.org, draft-ietf-core-echo-request-tag@ietf.org, core@ietf.org
Message-ID: <YPSOLVspH6FQ4TTi@hephaistos.amsuess.com>
References: <161359527152.11372.63177839446582675@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rWKSF1toZf7YgVp6"
Content-Disposition: inline
In-Reply-To: <161359527152.11372.63177839446582675@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/pscVPCLNQbqx38ilyjo4ThPuKZ0>
Subject: Re: [core] Roman Danyliw's No Objection on draft-ietf-core-echo-request-tag-12: (with COMMENT)
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, 18 Jul 2021 20:25:34 -0000

Hello Roman,

thanks for your input on echo-request-tag, and apologies for the delay
in processing them to completion.

Please see [1] for a few general comments; here are individual responses
to your comments:

> ** Section 5.  Per “As each pseudorandom number most only be used once …”, how will that be possible when echo values as small are 1-byte are possible?

Not all applications of Echo depend on pseudorandom numbers. Where they
do not, their construction can ensure that only unique 1-byte values are
used.until these are exhausted.

See also GENERIC-SHORT-ECHO[1].

> ** Section 5.
> However, this may not be an issue if the
>    communication is integrity protected against third parties and the
>    client is trusted not misusing this capability.  
> 
> -- Why is the use of integrity presented as only a possibility here?  Didn’t Section 2.3 require it when assuring the freshness requirement – “When used to serve freshness requirements including client aliveness and state synchronizing), the Echo option value MUST be integrity protected between the intended endpoints ...”
> -- Would it be clearer here to say that this is mitigation against an on-path attacker, not against rogue/compromised clients?

In the course of the GENERIC-SHORT-ECHO changes, this has been made more
precise using the concept of "authority over synchronized property"
introduced there.

> ** Appendix A helpfully tries to lay out recommendations.  A few comments:
> 
> -- all of the recommendations here have option values much larger than the permitted minimum of 1-byte.  In addition to the recommendations, could the circumstances of the lower bound also be discussed

Item 3 of appendix A can be as short as 1 byte (until it overflows to
2), with a concrete example linked, and includes a requirement for its
applicability.

> -- it would be helpful to explicitly state which methods apply to the specific use cases (client aliveness, request freshness, state synchronization, network  address reachability).  For example, method 3 (persistent counter) notes that it can be used for state synchronization but not client aliveness

These are now tied together by the Characterization chapter introduced
in GENERIC-SHORT-ECHO.


Best regards
Christian

[1]: https://mailarchive.ietf.org/arch/msg/core/SIHjiM5AjFRZJRZGUjf3cW1sUu4

-- 
This may seem a bit weird, but that's okay, because it is weird.
  -- perldata(1) about perl variables