Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

[Scott Kitterman <[e-mail]>]

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=
> 
> [e-mail]> 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