Re: [Last-Call] [OPSEC] Secdir last call review of draft-ietf-opsec-probe-attribution

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 23 Jun 2023 at 12:55, Eric Vyncke (evyncke) <evyncke@xxxxxxxxx> wrote:

Hello Tiru,

 

Thank you for your detailed review. I have submitted a revised I-D incorporating your suggestions.

 

Look below for EV> for further comments.

 

Best regards

 

-éric

 

From: OPSEC <opsec-bounces@xxxxxxxx> on behalf of tirumal reddy <kondtir@xxxxxxxxx>
Date: Tuesday, 20 June 2023 at 08:08
To: "secdir@xxxxxxxx" <secdir@xxxxxxxx>, "last-call@xxxxxxxx" <last-call@xxxxxxxx>, "draft-ietf-opsec-probe-attribution.all@xxxxxxxx" <draft-ietf-opsec-probe-attribution.all@xxxxxxxx>, "opsec@xxxxxxxx" <opsec@xxxxxxxx>
Subject: [OPSEC] Secdir last call review of draft-ietf-opsec-probe-attribution

 

Reviewer: Tirumaleswar Reddy
Review result:  Ready with issues

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is Ready with issues.

[1]
      else (or in addition), the Probe Description URI is
      "https://[2001:db8::dead]/.well-known/probing.txt".  In this case,
      there might be a certificate verification issue.

Comment> It is possible to get a certificate with IP address from a public CA
(see https://datatracker.ietf.org/doc/html/rfc8738).

EV> good catch, text amended


[2]

You may want to consider referring to https://datatracker.ietf.org/doc/draft-ietf-6man-hbh-processing/,
It discusses HBH option processing by intermediate nodes and recommendations to process new HBH options.

 

EV> I would prefer not to refer to a draft (and I fear that the 6MAN HbH is far from being published).


Sure but I suggest to high-light the issues with HBH options like the ones discussed in Section 4 of draft-ietf-6man-hbh-processing that at the time of writing this specification routers are typically configured to drop HBH options.
 


[3]
I suggest discussing the privacy implications that an eavesdropper will be able to view the PII data in the Probe.

EV> Added some note in the security section that no PII should be in the Probe Description (notably no personal address/email/phone). Good catch.


[4]
   As a consequence, the recipient of this information cannot trust it
   without confirmation. 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.

Comment> How can the recipient of the probe information validate it is authentic for confirmation ?

 

EV> applying common sense and doing some basic verification (e.g., is the email address valid ?). This is all about good faith.


Okay but you should suggest all possible checks like the scheme for the probe URI must be "https", email address is valid etc.

-Tiru
 

 

Cheers,

-Tiru

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux