Subject: [core] I-D Action: draft-ietf-core-echo-request-tag-12.txt

From: [email-masked]
Date: Mon, 01 Feb 2021 10:25:00 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Constrained RESTful Environments WG of the IETF.

        Title           : CoAP: Echo, Request-Tag, and Token Processing
        Authors         : Christian Amsüss
                          John Preuß Mattsson
                          Göran Selander
	Filename        : draft-ietf-core-echo-request-tag-12.txt
	Pages           : 34
	Date            : 2021-02-01

Abstract:
   This document specifies enhancements to the Constrained Application
   Protocol (CoAP) that mitigate security issues in particular use
   cases.  The Echo option enables a CoAP server to verify the freshness
   of a request or to force a client to demonstrate reachability at its
   claimed network address.  The Request-Tag option allows the CoAP
   server to match block-wise message fragments belonging to the same
   request.  This document updates RFC7252 with respect to the client
   Token processing requirements, forbidding non-secure reuse of Tokens
   to ensure binding of response to request when CoAP is used with a
   security protocol, and with respect to amplification mitigation,
   where the use of Echo is now recommended.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-core-echo-request-tag-12.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-echo-request-tag-12

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 1 Feb 2021 20:56:03 +0100

Hello Barry, hello Jürgen,

I've just uploaded a -12, and Marco has been very quick to update the
write-up.

All the points of the reviews have been addressed, and being nits
probably don't warrant further mention outside the changelog of the -12
(copied below for convenience).

The nontivial point was the lack of explanation about the number given
for OK-to-send responses. It has been recalculated with more
conservative numbers, experssed in what is hoped to be easier to consume
for implementation developers. For the "factor 3" that plays into it it
now refers to the WIP QUIC draft. It's giving the numbers as guidance in
case there's no better basis for making a more situation-adjusted and
more informed decision.

With that, the document should be good to go ahead.

Best regards, and thanks for all your input
Christian

---

   *  Changes since draft-ietf-core-echo-request-tag-11 (addressing
      GenART, TSVART, OpsDir comments)

      -  Explain the size permissible for responses before amplification
         mitigation by referring to the QUIC draft for an OK factor, and
         giving the remaining numbers that led to it.  The actual number
         is reduced from 152 to 136 because the more conservative case
         of the attacker not sending a token is considered now.

      -  Added a definition for "freshness"

      -  Give more concrete example values in figures 2 and 3 (based on
         the appendix suggestions), highlighting the differences between
         the figures by telling how they are processed in the examples.

      -  Figure with option summary: E/U columns removed (for duplicate
         headers and generally not contributing)

      -  MAY capitalization changed for consistency.

      -  Editorial changes (IV acronym expanded, s/can not/cannot/g)

      -  Draft ietf-core-stateless has become RFC8974

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Barry Leiba <[email-masked]>
Date: Mon, 1 Feb 2021 17:15:08 -0500

Thanks, Christian.  I’ve put it into IESG Evaluation.  It’s too late to
have it on this week’s IESG agenda, to it will come up for approval in two
weeks.

Barry