On Tue, Jul 4, 2023 at 5:20 AM tirumal reddy <[email protected]> wrote:
> Thanks for the review. Please see inline > > On Sat, 1 Jul 2023 at 10:41, Joseph Salowey via Datatracker < > [email protected]> wrote: > >> Reviewer: Joseph Salowey >> Review result: Has 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. >> >> This document is well written and useful. The document does have a good >> security considerations section but I think it could be improved. >> >> 1. I think it would be good to provide more context for the >> recommendations in >> the security considerations section (and for the processing rules in >> section >> 5.3). For example, the information in if untrusted information in the c, >> j and >> o fields are presented to an end user they may be used to misdirect the >> user to >> contact a malicious party to resolve their problem which could result in >> further compromise to the user's security (this could be worded better and >> there may be better examples). I think this may help readers to >> understand the >> implications of not following the recommendations. >> > > Good point, added the following text: > For example, an end user can use contact details in the "c" field to > contact an attacker > to solve the problem of being unable to reach a domain. The attacker can > mislead the end user to > install malware or spyware to compromise the device security posture or > mislead the end user to reveal > Personally Identifiable Information (PII). > > [Joe] Yes this helps. > >> 2. I find the SHOULD NOT make text clickable difficult. I don't think >> that the >> text should be clickable in general, but the contact field is essentially >> a >> series of link so the temptation is going to be to make it clickable. > > > Yes, that's the reason the above restriction is only imposed for "j" and > "o" fields. > > I think >> the document should describe better under what conditions the link can be >> clickable. Also its probably worth saying that the fields are rendered >> as text >> and not HTML. >> > > Yes, fixed to say these fields need to be rendered as text and not as HTML. > > [Joe] Why is this a SHOULD NOT instead of a MUST NOT, when is it appropriate that these fields are clickable? Is the intent that the "c" fields are clickable or not? > >> 3. Since links involved could be customized to the individual case privacy >> considerations may be needed. Following the contact links could possibly >> reveal >> information to another party. >> > > The proposed text to address comment#1 should address this issue as well. > > [Joe] I think the text helps. It is probably worth having a more privacy focused review here. It could be possible that the clickable links could be customized to provide user tracking, perhaps to reveal what sites the user is visiting to a third party. Perhaps an addition "...the user to reveal personal data or information about the sites they are connecting to." ? > >> 4. A little bit of a nit- In section 5.3 it says if the C and J fields are >> missing then discard the whole message, yet later there are cases where >> you >> MUST ignore the C and J fields and yet can still handle the S field. This >> seems a little contradictory to me, however I think technically its not a >> problem and would be implementable as it is. >> > > In the JSON schema, "c" and "j" fields are mandatory; hence the rule to > discard the EXTRA-TEXT field. However, these fields will be ignored in > several scenarios like opportunistic encryption mode or response from an > untrusted resolver. > > [Joe] Sounds good, thanks. > Cheers, > -Tiru >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
