>> This implies a deployment document based on the experiences of early >> adopters.
> I agree, but I think solving that is outside the scope of the current > document. +1. Ta. I. -- Dr Ian Levy Technical Director National Cyber Security Centre i...@ncsc.gov.uk Staff Officer : Kate Atkins, kat...@ncsc.gov.uk (I work stupid hours and weird times – that doesn’t mean you have to. If this arrives outside your normal working hours, don’t feel compelled to respond immediately!) -----Original Message----- From: dmarc <dmarc-boun...@ietf.org> On Behalf Of Scott Kitterman Sent: 20 July 2019 04:15 To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd On Friday, July 19, 2019 8:04:20 AM EDT Dotzero wrote: > I've been following the discussion but haven't contributed anything > until this point. Comment below. > > On Fri, Jul 19, 2019 at 3:29 AM Ian Levy <ian.levy= > > 40ncsc.gov...@dmarc.ietf.org> wrote: > > > I think this is one of those "you must be this tall to ride on > > > this ride" > > > situations. DNS comes equipped with multiple footguns and you > > > have to > > > > know a bit about what you're doing to make sure you get the effects > > you're after. > > > > This. DMARC today allows people to disconnect their outgoing mail > > from the rest of the world. Admittedly, the PSD-level policies would > > have a much greater effect, but your PSD/TLD operator can already > > bork you if they're not competent. > > There are two different buckets of risk in my view, though : > > 1) New TLDs are effectively greenfield sites and can enforce > > appropriate requirements on their customers from the start to > > minimize the chance of unintended consequences (for example, by requiring > > domain DMARC labels). > > 2) Existing TLDs, where there are many subdomains with wildly > > variable implementations, policies and use and here we are going to > > have to be really careful. Careful and methodical testing will be > > necessary to make sure that introduction of the PSD-level policies > > doesn't break anything important. It took us 6 months to get to > > synthesizing p=reject for non-existent subdomains of .gov.uk. A lot > > of that was analysing the data we got back and fixing stuff that we > > never expected (like Kerberos - don't ask!). I don't see why it > > would be different with the np= tag, but it will hopefully be much more > > limited in what we could mess up. > > > > I think we're really all worried about the second of these cases. If > > that's true, then I'm with Scott - if you don't understand this > > stuff, don't go and set an np tag on your PSD and cross your > > fingers. It's going to end badly. One of the things about doing the > > experiment is surely to help us understand how badly these can go > > wrong, so we can write down a bunch of ways not to do things. > > > > We can write in the document that scissors are sharp and running > > with sharp things can cause problems. But in the end, someone is > > going to run with scissors and get hurt. We can't code for every > > single case here and we surely must assume a level of competence of > > people implementing something like this. > > The problem, which we know or should know, is that DNS records are > apparently difficult to get right. We have a large corpus of data > points to back this up based on decades of experience. Even large, > supposedly experienced and technically qualified organizations shoot > themselves in the foot. Speaking as an original participant in the > dmarc.org team, I can't emphasize enough the education and > evangelization effort involved related to adoption (and misunderstanding of > how it works... or doesn't work). > > I think you are incorrect with your assumption regarding scenario #1. > I recently had a discussion with an owner/operator of a number of "new" TLDs. > They have no clue regarding this effort. So even if a TLD is new, that > does not mean it will implement from day 1. This means scenario #2 is > more likely the scenario to be dealt with (default) rather than #1. > Perhaps after some extended period of pain or if ICANN mandates > something, #1 will become the default, but I wouldn't hold my breath. > > With regard to scenario #2, it is not enough to simply say "don't run > with scissors". Some group, M3AAWG or ICANN or ISOC, will need to > educate and evangelize those outside the inner circle, so to speak. > I'm sure that companies like Agari, Dmarcian, Valimail, etc. will > gladly provide assistance., That TLD owner/operator I mentioned > earlier is not overly familiar with the space or those vendors. > > It is not enough for the creators of a proposed standard to state it's > technical validity. This implies a deployment document based on the > experiences of early adopters. I agree, but I think solving that is outside the scope of the current document. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarc&data=02%7C01%7Cian.levy%40ncsc.gov.uk%7C7c7b41070b5a449edbc008d70cc0908f%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C636991893511878654&sdata=Ng9fs%2FJa8R9Orm%2BPqtiq7IdLUXz0K%2FyyFLQRtGw%2FlJ4%3D&reserved=0 This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to ncscinfo...@ncsc.gov.uk. All material is UK Crown Copyright © _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
