THanks Tiru, This discussion has been really helpful for my understanding, just a few questions below:
On Mon, Jul 10, 2023 at 10:17 PM tirumal reddy <[email protected]> wrote: > 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). > > [Joe] And if I understand the intent of section 5.3, the "c" field will only be used if the 'strict privacy profile' is in use. > >> >>> >>>> 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). > > [Joe] OK this makes sense. The information will only be used if this is over an authenticated channel and any information that might be leaked could be disclosed more directly though some other channel. > -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
