On Fri, 23 Jun 2023 at 12:55, Eric Vyncke (evyncke) <evyn...@cisco.com> 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-boun...@ietf.org> on behalf of tirumal reddy < > kond...@gmail.com> > *Date: *Tuesday, 20 June 2023 at 08:08 > *To: *"sec...@ietf.org" <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
