Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-06.txt

[tirumal reddy]

We have created a PR to address the WG's feedback, please see
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error/pull/51/files.
The changes involve removing 'https' and adding 'mailto' as contact URI
schemes. We have also added a new registry for Contact URI schemes,
allowing the addition of new schemes based on IETF review.

-Tiru

On Fri, 20 Oct 2023 at 22:28, Dan Wing  wrote:

> The authors took a stab at text explaining mitigations which seem to have
> not met the WG's needs.
>
> Removing HTTP would allow the document to move forward.  If someone finds
> a suitable way to weaken (or even prevent) malicious use of http in the
> Contact field by the DoH/DoT operator (with an interstitial or something
> else) we can create a bis to allow http in the Contact ("c") field.
>
> -d
>
>
> On Oct 20, 2023, at 7:10 AM, Ben Schwartz  40meta@dmarc.ietf.org> wrote:
>
> This draft originally proposed returning a webpage.  After reviews from
> the working group raising concern about allowing the DNS server to inject a
> webpage, it was changed to provide a contact URI instead ... but it then
> lists "https:" as an example of a suitable contact URI scheme.  This
> apparent contradiction ("https:" is not a form of contact info) strikes me
> as an awkward compromise, and a fine example of "design by committee".
>
> Ultimately, it seems that this draft as aimed at browsers, and should
> provide information that browser makers believe can safely be displayed to
> users.  I think the most sensible solution is (1) replace the "https:"
> example in the draft with "mailto:; and (2) note that clients are free to
> ignore contact URIs with unsupported schemes.
>
> Even a "mailto:; scheme is not without risk here, and I wouldn't be
> surprised if some browser vendors feel it is unsafe to display.  However,
> it sounds like there is some interest from potential clients, perhaps
> enough to support continuing with this draft.
>
> --Ben
> --
> *From:* DNSOP  on behalf of tirumal reddy <
> kond...@gmail.com>
> *Sent:* Friday, October 20, 2023 6:09 AM
> *To:* Tommy Pauly 
> *Cc:* Vodafone Gianpaolo Angelo Scalone <
> Gianpaolo-Angelo.Scalone=40vodafone@dmarc.ietf.org>; DNSOP WG <
> dnsop@ietf.org>
> *Subject:* Re: [DNSOP] I-D Action:
> draft-ietf-dnsop-structured-dns-error-06.txt
>
> This Message Is From an External Sender
> I would like to clarify that the purpose of the "c" (contact) field is not
> to display an error page but to provide contact details of the IT/InfoSec
> team for reporting misclassified DNS filtering. Its function is to report
> legitimate domain names that have been incorrectly blocked due to
> misclassification.
>
> There is no mention in the draft that the "c" (contact) field is intended
> for displaying an error page. It is assumed that the client application
> would handle the display of an error page, and the content of the "c" field
> would be optionally used in specific scenarios, such as TRR.
>
> To improve clarity, we could update the draft and specify that the error
> page must be displayed by the client application, and the "c" field link
> may be optionally provided to raise complaints. Furthermore, to minimize
> security risks, the client can retrieve the URL from the contact field in
> an isolated environment. It must also take additional precautions, such as
> clearly labeling the page as untrusted. This isolation should prevent the
> transmission of cookies, block JavaScript execution, and prevent the
> auto-fill of credentials or personal information. The isolated environment
> should be separate from the user's normal browsing environment.
>
> Cheers,
> -Tiru
>
>
>
>
>
> On Fri, 20 Oct 2023 at 01:42, Tommy Pauly  40apple@dmarc.ietf.org> wrote:
>
>
>
> On Oct 19, 2023, at 12:44 PM, Warren Kumari  wrote:
>
> I still don't understand why (other than marketing/advertising) this is
> needed — the EDE "4.18. Extended DNS Error Code 17 - Filtered" ("The server
> is unable to respond to the request because the domain is on a blocklist as
> requested by the client. Functionally, this amounts to "you requested that
> we filter domains like this one.") seems to cover it.
>
> If browsers are willing to do anything with the EDE codes (like "ERROR:
> Your DNS filtering provider says you shouldn't go here") what additional
> **important** information needs to be communicated? And if browsers are not
> willing to do anything with just EDE codes, it sure doesn't seem like they
> would want to do that **and** follow an unauthenticated URL…
>
>
> Safari is now displaying the EDE-code based information! So we are willing
> to show that.
>
> The case that might still be interesting is providing the user some
> (hopefully safe) way to contact the blocker to dispute why this is being
> blocked — so a way to send an email to an administrator, but not something
> else. Showing advertising or marketing or any arbitrary page is not
> something I think would fly.

Re: [DNSOP] Automated delegation management via DDNS

[Paul Wouters]

On Oct 25, 2023, at 13:14, Johan Stenstam 
 wrote:
> 
> 
> To begin with it works equally well with or without DNSSEC.

That statements seems a little odd?

> Furthermore it is a cleaner solution than what we currently have (i.e. child 
> zone published CDS and/or CSYNC and parent at some future time will get 
> around to scan for it). Replacing all this this with a single DNS UPDATE is 
> something we should have (and could have) done long before either CDS or 
> CSYNC were invented.

You seem to assume we didn’t know this when CDS and CSYNC were created. The 
question to ask is, why at the time we thought those new mechanisms were 
needed, and whether those reasons have changed since then.


> The reason we didn’t was to some extent that we had higher hopes for DNSSEC 
> deployment rate than were justified, but primarily that we didn’t address the 
> question of how to figure out were to send the UPDATE when used across 
> organisational boundaries. Now we know more about the DNSSEC deployment rate 
> and we also have a proposal for locating the target for the UPDATE.

I don’t agree that adoption rate changes any justificstions  for new protocols. 

> And so this draft was born.

Mark pointed out we have those “where to send UPDATES” infrastructure already ?

> How many parent zones do we have in the universe? Millions, most likely. How 
> many of these parents have deployed CDS and CSYNC scanners? Perhaps a couple 
> of dozen. Compared to the deployment rate of DNSSEC in general the deployment 
> rate of CDS and CSYNC scanners is so completely lacking that I think we, i.e. 
> the DNS community, should ponder the following question very seriously:
> 
>Do we really think that CDS/CSYNC scanners are the only answer we need to 
> the question of how to achieve fullautomation of delegation information 
> between child and parent?
> 
> If the answer is “no” then I’d love to hear more suggestions than this 
> proposal.

I think you are confusing two very different use cases. Generic registration 
TLDs and DNS deployments within the same organization. The latter can clearly 
be done with stock DNS UPDATES. The TLD case is special as it involves the RRR 
ICANN model.

Any reasoning about deployments need to take this into account.

Paul
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Automated delegation management via DDNS

[Johan Stenstam]

On 28 Oct 2023, at 03:44, Paul Wouters  wrote:

>>> Scanners are, of course, inefficient, and notifications are a way to 
>>> improve that. I just think that as we are making comparisons, with 
>>> arguments whose strength is (in part) based on the number of queries 
>>> needed, we should get the order of magnitude right, to make the comparisons 
>>> as helpful as possible. That's all! :)
>> 
>> Then, as usual, we’re in agreement.
>> 
>> But to me, the place for analysis of scanner efficiency (or lack thereof) is 
>> in conjunction with the draft on generalised notifications and not here, as 
>> this draft explicitly is intended for the use cases where there is no 
>> scanner. :-)
> 
> The Wheel of Time turns, and Ages come and pass, leaving memories that
> become legend. Legend fades to myth, and even myth is long forgotten
> when the Age that gave it birth comes again. In one Age, this discussion
> was called "timers vs triggers". With no clear winner, nothing was done
> and thus people were forced to implementer scanners (timers). I'm happy
> to see notify (triggers) in some shape or form, although in previous
> wars, people wanted the notify to go "elsewhere", eg not the primary
> (or maybe not even secondary) servers as to leave the production name
> servers untouched.

I think most of us are in agreement here. That’s sort of the core intent
of draft-ietf-dnsop-generalized-notify.

> Note that I dont think scanners can be fully omitted, as any sane parent
> will do some sanity checks on its child and that's really just a scanner
> without a "for domain in TLD" loop around it.

I think this is also mostly agreed upon. Sanity check for sure. Whether
that requires a scanner or not depends (in my view) on the trigger. For a
NOTIFY a scan is obviously required to get the data to sanity check. For
an UPDATE it can be argued both ways.

Regards,
Johan



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop