On Fri, 23 Jun 2023 at 12:55, Eric Vyncke (evyncke)
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 on behalf of tirumal reddy <
> kond...@gmail.com>
> *Date: *Tuesday, 20 June 2023 at 08:08
> *To: *"sec...@ietf.org" , "last-c...@ietf.org" <
> last-c...@ietf.org>, "draft-ietf-opsec-probe-attribution@ietf.org" <
> draft-ietf-opsec-probe-attribution@ietf.org>, "opsec@ietf.org" <
> opsec@ietf.org>
> *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
>
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
