Thanks Stephane for the review. Please see inline On Sat, 2 Nov 2024 at 22:59, Stephane Bortzmeyer <bortzmeyer= 40nic...@dmarc.ietf.org> wrote:
> On Sat, Oct 26, 2024 at 10:10:43PM +0200, > Benno Overeinder <be...@nlnetlabs.nl> 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 -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
