On Wed, 12 Jul 2023 at 21:37, Joseph Salowey <j...@salowey.net> wrote:
> 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 <kond...@gmail.com> wrote: > >> On Mon, 10 Jul 2023 at 10:22, Joseph Salowey <j...@salowey.net> wrote: >> >>> >>> >>> On Tue, Jul 4, 2023 at 5:20 AM tirumal reddy <kond...@gmail.com> wrote: >>> >>>> 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). >>>> >>>> [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. > Yes, your understanding is correct and even in the strict privacy profile, the client might choose to display the information in the "c" field only if the resolver has sufficient reputation (e.g., a trusted recursive resolver). -Tiru > > >> >>> >>>> >>>>> 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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
