remove https in the example

[boucadair]

No description provided.

[tireddy2]

we need text to say that only "mail", "sips" and "tel" URI schemes will be allowed by this specification and an IANA registry with specification required will be required to allow new URI schemes. This way new schemes can be created without bis document.

[danwing]

On Oct 21, 2023, at 6:32 AM, Tirumaleswar Reddy ***@***.***> wrote: @tireddy2 commented on this pull request. In draft-ietf-dnsop-structured-dns-error.md <#51 (comment)>: > @@ -261,7 +261,7 @@ c: (contact) : The contact details of the IT/InfoSec team to report mis-classified DNS filtering. This information is important for transparency and also to ease unblocking a legitimate domain name that got blocked due to wrong classification. : This field is structured as an array of contact URIs -(e.g., 'tel' {{?RFC3966}}, 'sips' {{?RFC5630}}, 'https' {{?RFC8615}}). At least one contact URI MUST be +(e.g., 'tel' {{?RFC3966}} or 'sips' {{?RFC5630}}). At least one contact URI MUST be included. we need text to say that only "mail", "sips" and "tel" URI schemes will be allowed by this specification and an IANA registry with specification required will be required to allow new URI schemes. This way new schemes can be created without bis document.

With all the concern on the list over having "http" on the list, extending such a registry would need a higher bar than 'designated expert'. Would need at *least* specification required but that's probably too low a bar, as well. The choices are at https://www.ietf.org/rfc/bcp/bcp26.html for easy reference. I would say it needs IETF Review. If that is the bar, though, I wouldn't bother with an IANA registry. Someone who wants to extend the list can just write an RFC that adds "http" (or whatever schema they like). Or do we now need to IANA registry All The Things?

…

-d

[tireddy2]

On Oct 21, 2023, at 6:32 AM, Tirumaleswar Reddy @.***> wrote: @tireddy2 commented on this pull request. In draft-ietf-dnsop-structured-dns-error.md <#51 (comment)>: > @@ -261,7 +261,7 @@ c: (contact) : The contact details of the IT/InfoSec team to report mis-classified DNS filtering. This information is important for transparency and also to ease unblocking a legitimate domain name that got blocked due to wrong classification. : This field is structured as an array of contact URIs -(e.g., 'tel' {{?RFC3966}}, 'sips' {{?RFC5630}}, 'https' {{?RFC8615}}). At least one contact URI MUST be +(e.g., 'tel' {{?RFC3966}} or 'sips' {{?RFC5630}}). At least one contact URI MUST be included. we need text to say that only "mail", "sips" and "tel" URI schemes will be allowed by this specification and an IANA registry with specification required will be required to allow new URI schemes. This way new schemes can be created without bis document.
With all the concern on the list over having "http" on the list, extending such a registry would need a higher bar than 'designated expert'. Would need at least specification required but that's probably too low a bar, as well. The choices are at https://www.ietf.org/rfc/bcp/bcp26.html for easy reference. I would say it needs IETF Review.
If that is the bar, though, I wouldn't bother with an IANA registry. Someone who wants to extend the list can just write an RFC that adds "http" (or whatever schema they like). Or do we now need to IANA registry All The Things?

…
-d

On Oct 21, 2023, at 6:32 AM, Tirumaleswar Reddy @.***> wrote: @tireddy2 commented on this pull request. In draft-ietf-dnsop-structured-dns-error.md <#51 (comment)>: > @@ -261,7 +261,7 @@ c: (contact) : The contact details of the IT/InfoSec team to report mis-classified DNS filtering. This information is important for transparency and also to ease unblocking a legitimate domain name that got blocked due to wrong classification. : This field is structured as an array of contact URIs -(e.g., 'tel' {{?RFC3966}}, 'sips' {{?RFC5630}}, 'https' {{?RFC8615}}). At least one contact URI MUST be +(e.g., 'tel' {{?RFC3966}} or 'sips' {{?RFC5630}}). At least one contact URI MUST be included. we need text to say that only "mail", "sips" and "tel" URI schemes will be allowed by this specification and an IANA registry with specification required will be required to allow new URI schemes. This way new schemes can be created without bis document.
With all the concern on the list over having "http" on the list, extending such a registry would need a higher bar than 'designated expert'. Would need at least specification required but that's probably too low a bar, as well. The choices are at https://www.ietf.org/rfc/bcp/bcp26.html for easy reference. I would say it needs IETF Review. If that is the bar, though, I wouldn't bother with an IANA registry. Someone who wants to extend the list can just write an RFC that adds "http" (or whatever schema they like). Or do we now need to IANA registry All The Things?
…
-d

Good points, IETF review sounds good to me. IANA registry helps avoid the need to for an implementer to follow multiple documents to support this specification. We can also add a "Recommended" column to indicate the schemes that implementations are recommended to support.

[danwing]

New in this edit I see:

The client MUST handle the display of an error page to the end-user. The "c," "j," and "o" fields MUST NOT be used to display an error page.

The client might not want to generate an error page at all; maybe it just wants to log to a file. Who knows. I also disagree with "The ... fields MUST NOT be used", well, then, what is supposed to be used?? I don't get this edit at all. I mean, the intent of eliminating https from "c" was so that sip/tel/mailto would be 'safer' to show to the user. But now we can't show?

I would just delete this new paragraph ("The client MUST handle the display...") starting on line 497 of the version I see here on Github.

[danwing]

If the client can display an error page to the end-user, it MUST generate the error page. The "c," "j," and "o" fields MUST NOT be used to display an error page.

Wording of the first sentence is improved, but I don't get why we're stating that. I mean, a browser could display an error page. But it still may have reasons not to, including a configuration setting! Which means it violated the MUST. And maybe it never had code to display anything to the user, but rather just to report back to IT (so IT can automatically fix mis-classified filters now that IT can correlate the DNS query to the user and probably the user's URL, all automatically with cooperating software on the client).

I am still confused by "The ... fields MUST NOT be used to display an error". Why have that constraint? Is mailto: not safe enough to show the user? And still not safe enough for the user to click on it? If those fields aren't displayed, what would be displayed to the user, nothing from this I-D?

[boucadair]

Not sure to get what is the purpose of:

"If the client can display an error page to the end-user, it MUST generate the error page"

[tireddy2]

I will remove this line.

[boucadair]

I will remove this line.

Thanks, Tiru

[tireddy2]

If the client can display an error page to the end-user, it MUST generate the error page. The "c," "j," and "o" fields MUST NOT be used to display an error page.

Wording of the first sentence is improved, but I don't get why we're stating that. I mean, a browser could display an error page. But it still may have reasons not to, including a configuration setting! Which means it violated the MUST. And maybe it never had code to display anything to the user, but rather just to report back to IT (so IT can automatically fix mis-classified filters now that IT can correlate the DNS query to the user and probably the user's URL, all automatically with cooperating software on the client).

I am still confused by "The ... fields MUST NOT be used to display an error". Why have that constraint? Is mailto: not safe enough to show the user? And still not safe enough for the user to click on it? If those fields aren't displayed, what would be displayed to the user, nothing from this I-D?

I raised this text to address the comment from the WG that "https:" field could be misused by the DNS operator to display a fancy error page with advertisements or a phishing page similar to the one provided by the origin server. I would like to convey the message that "c", "o" and "j" fields must not be used to generate a error page but the contents of these fields can possibility be displayed in the error page generated by the client. How about the following text ?

It is important to clarify that the 'c,' 'o,' and 'j' fields MUST NOT be utilized for generating an error page. However, it is worth noting that the content of these fields could be incorporated into error page generated by the client.

[bemasc]

Personally, I don't like having an IANA registry for this. I would prefer to leave the text as previously, with no particular limitation on the schemes in use, and simply change the examples to replace "https" (which is a strange example for a "contact URI") with "mailto" (which is the most obvious example).

We could also add some text noting that clients MAY ignore any schemes that they do not feel are safe to support, and SHOULD exercise caution before adding support for new schemes.

[tireddy2]

Personally, I don't like having an IANA registry for this. I would prefer to leave the text as previously, with no particular limitation on the schemes in use, and simply change the examples to replace "https" (which is a strange example for a "contact URI") with "mailto" (which is the most obvious example).

This would allow any other scheme like 'https' scheme to be used. The revised draft ensures that only safe schemes are permitted.

We could also add some text noting that clients MAY ignore any schemes that they do not feel are safe to support, and SHOULD exercise caution before adding support for new schemes.

The client may not know whether a new scheme is safe or not. The IETF review process ensures that only safe schemes are permitted, relieving clients from the need to perform threat analysis.

[tireddy2]

If the client can display an error page to the end-user, it MUST generate the error page. The "c," "j," and "o" fields MUST NOT be used to display an error page.

Wording of the first sentence is improved, but I don't get why we're stating that. I mean, a browser could display an error page. But it still may have reasons not to, including a configuration setting! Which means it violated the MUST. And maybe it never had code to display anything to the user, but rather just to report back to IT (so IT can automatically fix mis-classified filters now that IT can correlate the DNS query to the user and probably the user's URL, all automatically with cooperating software on the client).

I am still confused by "The ... fields MUST NOT be used to display an error". Why have that constraint? Is mailto: not safe enough to show the user? And still not safe enough for the user to click on it? If those fields aren't displayed, what would be displayed to the user, nothing from this I-D?

The comment is addressed.