[DNSOP] Re: Working Group Last Call draft-ietf-dnsop-structured-dns-error

[tirumal reddy <[e-mail]>]

Thanks Stephane for the review. Please see inline

On Sat, 2 Nov 2024 at 22:59, Stephane Bortzmeyer <bortzmeyer=
[e-mail]> wrote:

> On Sat, Oct 26, 2024 at 10:10:43PM +0200,
>  Benno Overeinder <[e-mail]> wrote
>  a message of 25 lines which said:
>
> > This initiates the Working Group Last Call (WGLC) for
> > draft-ietf-dnsop-structured-dns-error, "Structured Error Data for
> Filtered
> > DNS."
>
> The draft is very useful (users need to be informed) and I think the
> solution chosen (I-JSON in the EXTRA-TEXT) is reasonable. The draft is
> clear. But there are two issues, one being serious.
>
> The "j" field is in natural language but there is no way to tag it wth
> the language used. (RFC 2277, section 4.2). There is a note "If the
> text is displayed in a language not known to the end user, browser
> extensions to translate to user's native language can be used." which
> is useless (the text will probably be short and therefore detecting
> the langague used will be a challenge; also, there are not only
> browsers in the field). I suggest to delete the sentence and either to
> add a field to tag the language (RFC 5646) or, if it's a too important
> change, add a sentence like "The text will be in natural language,
> chosen by the DNS administrator to match its expected audience".
>

Good point, we updated the draft
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error/blob/main/draft-ietf-dnsop-structured-dns-error.md
to address both the comments. "l" field is added to indicate the language
used for the JSON-encoded "j" and "o" fields. The text related to browser
extension is deleted.


>
> Less serious, when discussing the alternative (forged IP address and a
> Web page to explain the censorship), the draft says "If an HTTPS
> enabled domain is blocked, the block page is also served over HTTPS.
> In order to return a block page over HTTPS, man in the middle (MITM)
> is enabled on endpoints by generating a local root certificate and an
> accompanying (local) public/private key pair. " All the arguments in
> the draft against using a Web page to inform the user are for
> HTTPS. But the draft should add that, even with HTTP, this "solution"
> raises a privacy problem: the HTTP server will see the IP address of
> the client and the host name requested. (If you read french, this page
> from the government
> <
> https://www.interieur.gouv.fr/Archives/Archives-des-actualites/2016-Actualites/Redirection-vers-la-page-de-blocage-des-sites-terroristes-pour-les-clients-de-l-operateur-orange
> >
> discusses what happened after a configuration error redirecting many
> users to a governement page accusing them of trying to access
> terrorist resources. The governement claims it requested the deletion
> of the HTTP server logfile. Note that this governement promised years
> ago to not log this data.)
>

Thanks, added the privacy issue of sharing the endpoint IP address and
domain name accessed by the user with the HTTPS server.

Cheers,
-Tiru


>
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>