Thanks for the review. Please see inline On Sat, 1 Jul 2023 at 10:41, Joseph Salowey via Datatracker < nore...@ietf.org> 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). > 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. > > 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. > > 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. Cheers, -Tiru
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
