[OPSEC] Roman Danyliw's Abstain on draft-ietf-opsec-probe-attribution-09: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-opsec-probe-attribution-09: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsec-probe-attribution/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Tiru Reddy for the SECDIR review.

Thank you for addressing my COMMENT feedback.

===
It isn’t clear how the safest practice is not to always ignore this attribution
information.

** The text notes in numerous places that this is only intended for
“researchers with good intentions” (Section 1 and 7) but it isn’t clear how
this intention translates into the workflow of the probe recipient (i.e., how
does a recipient know it came from someone with good intentions?).  The
mechanism defined here seems to expect circumstances on the internet which are
inconsistent with the internet threat model (RFC3552) that cautions against
assuming that entities on a path having "good intentions."

Specifically:

-- Per the out-of-band attribution (Section 3), the suggested workflow is
directing a network defender to visit an arbitrary location of the attackers
choosing (i.e., by spoofing the probe source address) or by redirecting the
defender to an infrastructure controlled by the attacker.  This seems risky as
this location could be serving malware or the connection itself could be
facilitating a DDOS reflector-style attack (if automated processing of this
information is done by the network defender).  Just because the probe
description file is specified as a text file doesn't mean that this is what
will be served by the attacker controlled infrastructure.

-- Per the in-path attribution (Section 4), there are no integrity guarantees
so any on-path attacker could also modify legitimate attribution information to
information of their choosing.  See out-of-band attribution.

** Section 7.
   If a recipient cannot confirm the information
   or does not wish to do so, it should treat the flows as if there were
   no probe attribution.

What does confirmation mean in this case?  How is that realized?  Per the
URI-based attribution, there is no strong binding between the sender and the
information.  As the Section 7 text notes, nothing prevents false attribution
(i.e., attributing the traffic to someone else to cover my own behavior) or a
false flag (e.g., attributing the traffic to someone else so as to blame them)?
 Additionally, nothing prevents an attacker from staffing a response to an
email or telephone provided in the URI.  If the network defender makes contact
via provided mechanisms, why should there be any confidence in that
communication?