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. Just a few thoughts. Michael Hammer
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
