Re: [dmarc-ietf] DBOUND
On Mon, Oct 16, 2023 at 8:35 PM Neil Anuskiewicz wrote: > The reference to DBOUND was sparked by looking around at what w3aawg was > saying as I generally think they have some good papers and a great video > series on email authentication. But what I found on DBOUND isn’t > endorsement. They framed DBOUND in a positive light and encouraged people > to look into the project but that doesn’t mean the organization endorses > it. > DBOUND was an attempt to create, in the DNS, a mechanism that could do what the PSL does. There were essentially two proposals: Making assertions from the top down, and making assertions from the bottom up. You could liken these to the cookies case and the DMARC case. Sadly, there was no convergence and thus no consensus, so the WG disbanded (over six years ago) without producing anything. I'm not sure why a M3AAWG statement dated April of this year would make reference to it as if it were current. There was an attempt to restart the working group within the last year or so, but that push was not sufficiently organized to sustain a rechartering effort. The working group remains closed, though the mailing list remains open. -MSK, ART AD ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DBOUND
On Oct 16, 2023, at 6:48 PM, Neil Anuskiewicz wrote: > > >> On Oct 16, 2023, at 6:43 PM, Seth Blank >> wrote: >> >> I'm sorry, to what are you referring? I co-chair the M3AAWG technical >> committee, and am unaware of any advocacy for relitigating DBOUND... Seth, I based my statement on wording in a couple documents and I heard it from other sources but I think I’m just flat out wrong w3aawg is supporting DBOUND. I did not mean it as a pejorative, it was more interest in why they might be supporting it. I don’t anything about DBOUND. It looked like the project was a an active project, so I was curious about it and why M3AAWG might have taken an interest. But jumping from that to support was too big a leap. My goal for being on this list is to learn and that’s been great. So the next thing would be how to use what I learn to be helpful. It’s challenging to figure out how to be helpful to the WG so I’ve been thinking of other ways such as other content to help others understand. The reference to DBOUND was sparked by looking around at what w3aawg was saying as I generally think they have some good papers and a great video series on email authentication. But what I found on DBOUND isn’t endorsement. They framed DBOUND in a positive light and encouraged people to look into the project but that doesn’t mean the organization endorses it. The last thing I wanted to do is offend anyone here. I’d like to continue to learn and possibly contribute to the larger DMARCbis effort. So again, I apologize. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DBOUND
It appears that Neil Anuskiewicz said: >-=-=-=-=-=- >See section V Enaging with DBOUND is not the same thing as advocating that DBOUND do anything specific. Everyone agrees the PSL is awful, including the people who maintain it. But there's no agreement at all about what would be better. DMARC managed to get away from the PSL because unlike every other PSL application, it can put its own markers in the DNS. Quite a while ago I came up with a tricky way to put the whole PSL in the DNS and do look ups efficiently (one lookup per boundary, which typically means one lookup total.) But people who write web browsers that use it to manage cookies said no, that's too slow, and we haven't made any perceptible progress since then. R's, John >> On Oct 16, 2023, at 6:43 PM, Seth Blank >> wrote: >> > > >> I'm sorry, to what are you referring? I co-chair the M3AAWG technical >> committee, and am unaware of any advocacy for relitigating DBOUND... >> On Mon, Oct 16, 2023 at 6:36� �PM Neil Anuskiewicz >> wrote: >> >> M3AAWG is advocating for DBOUND as most of you likely know. Does it seem >> a viable alternative? We could sure use the support of M3AAWG. How could >> we earn their support or are they committed to DBOUND? >> >> Perhaps once we prove that DMARCbis works they� ll reconsider. >> >> Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DBOUND
See section VOn Oct 16, 2023, at 6:43 PM, Seth Blank wrote:I'm sorry, to what are you referring? I co-chair the M3AAWG technical committee, and am unaware of any advocacy for relitigating DBOUND...On Mon, Oct 16, 2023 at 6:36 PM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:M3AAWG is advocating for DBOUND as most of you likely know. Does it seem a viable alternative? We could sure use the support of M3AAWG. How could we earn their support or are they committed to DBOUND? Perhaps once we prove that DMARCbis works they’ll reconsider. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc -- Seth Blank | Chief Technology Officere: s...@valimail.comp: This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DBOUND
On Oct 16, 2023, at 6:43 PM, Seth Blank wrote:I'm sorry, to what are you referring? I co-chair the M3AAWG technical committee, and am unaware of any advocacy for relitigating DBOUND...On Mon, Oct 16, 2023 at 6:36 PM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:M3AAWG is advocating for DBOUND as most of you likely know. Does it seem a viable alternative? We could sure use the support of M3AAWG. How could we earn their support or are they committed to DBOUND? Perhaps once we prove that DMARCbis works they’ll reconsider. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc In this document on the site, toward the bottom they encourage support for it. I found the same thing in another similar document. https://www.m3aawg.org/sites/default/files/m3aawg_present_and_future_of_the_public_suffix_list.docx_.pdfNo offense intended, sir. I apologize if I’m wrong. It does appear they are supporting it by the wording.Neil___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DBOUND
I'm sorry, to what are you referring? I co-chair the M3AAWG technical committee, and am unaware of any advocacy for relitigating DBOUND... On Mon, Oct 16, 2023 at 6:36 PM Neil Anuskiewicz wrote: > M3AAWG is advocating for DBOUND as most of you likely know. Does it seem a > viable alternative? We could sure use the support of M3AAWG. How could we > earn their support or are they committed to DBOUND? > > Perhaps once we prove that DMARCbis works they’ll reconsider. > > Neil > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank * | Chief Technology Officer *e:* s...@valimail.com *p:* This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DBOUND
M3AAWG is advocating for DBOUND as most of you likely know. Does it seem a viable alternative? We could sure use the support of M3AAWG. How could we earn their support or are they committed to DBOUND? Perhaps once we prove that DMARCbis works they’ll reconsider. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DBOUND
Some time back there was an attempt to solve the PSL problem in DNS via a Domain Boundaries (DBOUND) working group. It was not successful, unable to develop consensus among several options, and the working group closed having not produced anything. The WG page: https://www.ietf.org/mailman/listinfo/dbound There is now some interest in seeing if a new run at that work would succeed. This might be of significant interest to DMARC if it were to work out this time. There may be a side meeting to discuss it at IETF 114. If you might be interested in participating or supporting that work, feel free to subscribe to their list. -MSK, ART AD ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt
On 4/3/2019 12:19 PM, tjw ietf wrote: I was going to say CAA but that’s 6 years old. 5 was a random number. I was merely meaning 'recent'. But suggesting CAA in response to my query means that you think RFC 6844 has received widespread -- ie, at scale -- end to end adoption and use. Yes? Please forgive my skepticism. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt
On 03/04/2019 21:19, Jothan Frakes wrote: >> ... registrar >> GUIs are perhaps the main barrier for new RRTYPEs ... > > s/registrar/DNS Management/ > > these are often not one in the same - and the only reason I make that > pedantic distinction is that the frequent situation where > DNS Management != registrar > heavily impedes DNSSEC end-to-end configuration, because it needs > config harmony within the registration path (registrar) and the > resolution path (DNS) > > Hope that made sense. Just want to ensure these are not conflated to > avoid drag on efforts Fair point. Ta, S. > > ___ > dbound mailing list > dbo...@ietf.org > https://www.ietf.org/mailman/listinfo/dbound > 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt
> ... registrar > GUIs are perhaps the main barrier for new RRTYPEs ... s/registrar/DNS Management/ these are often not one in the same - and the only reason I make that pedantic distinction is that the frequent situation where DNS Management != registrar heavily impedes DNSSEC end-to-end configuration, because it needs config harmony within the registration path (registrar) and the resolution path (DNS) Hope that made sense. Just want to ensure these are not conflated to avoid drag on efforts ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt
Far from widely deployed, but the latest ESNI draft introduced a new RRTYPE from an experimental range, and it "just worked," which was a pleasant surprise for me. (And is partly why I am happy to try that route for RDBD.) "just worked" here meaning: no registrar web-GUI involved, but whacking the ascii hex encoding of binary RR values into a zonefile on a hidden master, having that transferred to the visible NS's and accessing it from elsewhere using dig with and without DNS/TLS (DoT- flavoured via stubby) all did really just work. Only hard thing was finding the docs to say how to refer to the new RRTYPE in zonefile and dig command line. (I added some notes on that in a readme for my ESNI code - go to [1] and search down for RRTYPE if you're curious.) I think that tends to back up John's argument that today, registrar GUIs are perhaps the main barrier for new RRTYPEs that don't change the DNS semantically. But there may also be development environment issues, e.g. I don't know if you can easily query for new RRTYPEs from e.g. PHP or python code. Lastly, on Dave's draft itself, I'd be happy if something like that were deployed, and don't think it overlaps much with or competes with RDBD. (At least I hope these aren't seen as competing ideas.) In early chats about RDBD Alex and I did think about the PSL, but we ended up deliberately not trying to aim for a DNS equivalent. Without trying to speak for Alex, personally I think emulating the PSL in DNS is too big a leap to attempt in one step and isn't likely to succeed, despite it being an outcome that'd be good to (eventually) see. That's partly how we ended up with (what I'd claim) is the more modest initial goal of RDBD. Cheers, S [1] https://github.com/sftcd/openssl/tree/master/esnistuff On 03/04/2019 20:19, tjw ietf wrote: > I was going to say CAA but that’s 6 years old. > > > > From my high tech gadget > >> On Apr 3, 2019, at 20:06, John R Levine wrote: >> >>> On Wed, 3 Apr 2019, Dave Crocker wrote: >>> Now, about /end to end/ support, not just publishing... >>> >>> Please provide some examples comparable to your proposed use case. That >>> is, what are new RRs that are getting well-scaled, on-going use, defined in >>> say the last 5 years? >> >> There aren't many other than maybe CDS and CDSKEY. TLSA was defined in 2012 >> and Viktor says it's getting pretty wide use now, particularly considering >> that it needs DNSSEC. >> >> On the other hand, there hasn't been anything with new server semantics >> since NSEC3 in 2008. >> >> This is really an argument for dnsop, not dmarc or dbound. >> >> Regards, >> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY >> Please consider the environment before reading this e-mail. https://jl.ly >> >> ___ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc > > ___ > dbound mailing list > dbo...@ietf.org > https://www.ietf.org/mailman/listinfo/dbound > 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt
I was going to say CAA but that’s 6 years old. From my high tech gadget > On Apr 3, 2019, at 20:06, John R Levine wrote: > >> On Wed, 3 Apr 2019, Dave Crocker wrote: >> Now, about /end to end/ support, not just publishing... >> >> Please provide some examples comparable to your proposed use case. That is, >> what are new RRs that are getting well-scaled, on-going use, defined in say >> the last 5 years? > > There aren't many other than maybe CDS and CDSKEY. TLSA was defined in 2012 > and Viktor says it's getting pretty wide use now, particularly considering > that it needs DNSSEC. > > On the other hand, there hasn't been anything with new server semantics since > NSEC3 in 2008. > > This is really an argument for dnsop, not dmarc or dbound. > > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt
On Wed, 3 Apr 2019, Dave Crocker wrote: Now, about /end to end/ support, not just publishing... Please provide some examples comparable to your proposed use case. That is, what are new RRs that are getting well-scaled, on-going use, defined in say the last 5 years? There aren't many other than maybe CDS and CDSKEY. TLSA was defined in 2012 and Viktor says it's getting pretty wide use now, particularly considering that it needs DNSSEC. On the other hand, there hasn't been anything with new server semantics since NSEC3 in 2008. This is really an argument for dnsop, not dmarc or dbound. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt
On 4/3/2019 11:52 AM, Jothan Frakes wrote: I fear that unless we can ensure that some of the dependencies are met by those proposals, the proposals will not endure, and we'll remain using the PSL in a status quo manner. Jothan, Thanks for adding comments so quickly after the draft was released. As the draft notes, it attempts to cover PSL use cases but needs far more experienced eyes and minds to find where the PSL emulation needs more work. To that end, anything that documents the dependencies you cite is sure to help. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt
I appreciate the time you invested in this Dave. I definitely like that we're thinking in terms of how to leverage DNS and its distributed model vs emulating the hosts.txt situation, and PSL is essentially a hosts.txt situation. Some assert there is a benefit to being able to contain some form of static list locally for speed. This happens at the trade-off of potentially stale data, which we experience as maintainers receiving energy from expressive TLD admins describing their grief over their domains being directed at search instead of resolving in DNS because their pc, tablet or mobile device runs a browser software that did not contain their TLD. So in those cases (and potentially others) getting things into DNS _might_ be better. I think that a TLD administrator being able to make direct updates in their own zones is vastly better because it would both alleviate the arduous process of validating authority of requests, and streamline the requesting process to near zero on their updates, and enable more direct and exacting control by the registry operators. That said, we fail the community unless the potential replacements take into consideration the many constituent / subjective uses of PSL that have evolved across the years before we tick the box next to any particular solution meeting the diverse needs. We have to tread carefully here. I have great respect for the IETF and the many wise and noble experts that have donated their experience, time and wisdom towards solutions and standards. It is a process that requires patience and I have been told by many in the developer community that it is not always one that is inclusive or able to meet the pace of some development cycles and product or service evolution. The PSL basically came into existence outside of the IETF process, borne of real practical needs, and those needs have forked and matured. There is a 'lenticular' / perspective issue in how different stakeholders are using the PSL. PSL is included in software libraries, which incorporate it without prescribing how a developer might use it. Some care only about the private section of the list, some only about the "ICANN" section. Some integrators of the PSL omit certain elements, or even maintain their own supplementary sections for their project or service needs. Think it is safe to assert variety is present - each have an entirely different need and application of some or all of the PSL's contents than a browser program, search engine, security professional, anti-spam, reporting, SSL Cert, or other use. We (maintainers) don't prescribe specifically how it gets used as volunteer community maintainers, we just try to guide community entries and validate them (and focus on ICP-3 or other I* integrity). PSL is expanding - which grows the file size each time. As potential solutions are presented from web developers or even the IETF (or both) that might help to organize or better architect solutions that could help PSL from heading towards something that emulates the transition from the SRI hosts.txt challenges, I fear that unless we can ensure that some of the dependencies are met by those proposals, the proposals will not endure, and we'll remain using the PSL in a status quo manner. -Jothan Jothan Frakes On Wed, Apr 3, 2019 at 10:58 AM John Levine wrote: > > In article <3bebe973-0536-96cd-983e-240ba4346...@dcrocker.net> you write: > >Comments eagerly sought, of course. > > This seems sorta kinda like my dbound draft, only with _tagged TXT > records rather than a new rrtype, and (unless I missed something) a > hope that somehow you can use a yet to be invented cache to avoid > walking up the tree, where mine used wildcards to do one lookup per > boundary regardless of the tree depth. > > I can see that the tradeoffs are different but I don't see why they're better. > > R's, > John > > >A new version of I-D, draft-dcrocker-dns-perimeter-00.txt > >has been successfully submitted by D. Crocker and posted to the > >IETF repository. > > > >Name: draft-dcrocker-dns-perimeter > >Revision: 00 > >Title: DNS Perimeter Overlay > >Document date: 2019-04-02 > >Group: Individual Submission > >Pages: 20 > >URL: > >https://www.ietf.org/internet-drafts/draft-dcrocker-dns-perimeter-00.txt > > ___ > dbound mailing list > dbo...@ietf.org > https://www.ietf.org/mailman/listinfo/dbound ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt
On 4/3/2019 11:45 AM, John R Levine wrote: On Wed, 3 Apr 2019, Dave Crocker wrote: In my experience, these days getting a new rrtype that doesn't have extra semantics into DNS servers happens pretty quickly. Now, about /end to end/ support, not just publishing... Please provide some examples comparable to your proposed use case. That is, what are new RRs that are getting well-scaled, on-going use, defined in say the last 5 years? My dbound draft has no new DNS semantics, just ordinary wildcards and an ordinary rrtype. I noted that. To put anything into the additional section, you're asking the DNS servers to treat a _perim name specially if there are TXT records under I noted that. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt
On Wed, 3 Apr 2019, Dave Crocker wrote: Section 7's suggestion for using Additional information does not rely on caching. Reliance on existing wildcard depends on propagation of a new RR, which continues to be problematic. There's a reason the Attrleaf table has so many entries... Now we're having a discussion about which is the frying pan and which is the fire. In my experience, these days getting a new rrtype that doesn't have extra semantics into DNS servers happens pretty quickly. It's an entry in a table or a new short stylized parse/unparse routine. DNS caches don't have to change at all. The problem is the web provisioning crudware, which is what I have tried with limited success to address with my DNS extension language work. My dbound draft has no new DNS semantics, just ordinary wildcards and an ordinary rrtype. To put anything into the additional section, you're asking the DNS servers to treat a _perim name specially if there are TXT records under the name and to go search through the zone to find the extra stuff and put it in the additional section. DNS caches have to change too, to treat the additional stuff as non-hostile and pass it through, since caches throw away unrecongnized additional sections to prevent cache poisoning (the Kashpureff bug.) You should run this by dnsop where I expect you'll get a great deal of pushback and references to the DNS Camel for anything with new semantics. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt
On 4/3/2019 10:58 AM, John Levine wrote: In article <3bebe973-0536-96cd-983e-240ba4346...@dcrocker.net> you write: Comments eagerly sought, of course. This seems sorta kinda like my dbound draft, only with _tagged TXT records rather than a new rrtype, and (unless I missed something) a hope that somehow you can use a yet to be invented cache to avoid walking up the tree, where mine used wildcards to do one lookup per boundary regardless of the tree depth. Section 7's suggestion for using Additional information does not rely on caching. Reliance on existing wildcard depends on propagation of a new RR, which continues to be problematic. There's a reason the Attrleaf table has so many entries... And while there is certainly conceptual overlap with your earlier proposal, the current one has differences I'd class as significant. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
