On Mon, 10 Jul 2023 at 10:22, Joseph Salowey <[email protected]> wrote:
> > > 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? > I can't think of any valid reason why these fields should be clickable, we will modify it to "MUST NOT". > > Is the intent that the "c" fields are clickable or not? > Yes, "c" field can be clickable (to make a VOIP call). > > >> >>> 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." ? > The DNS resolver would anyway know the domains the user is visiting and can possibly share that information with a third party. Trusted recursive resolvers need to meet the policy requirements of the clients (for example, see https://www.rfc-editor.org/rfc/rfc8932.html#section-5.3.3). The fields will not be displayed unless the resolver is trusted and even when the resolver is trusted, none of the fields are clickable (excluding the "c" field). -Tiru > > >> >>> 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
