Re: [dmarc-ietf] PSD simplification

[Dave Crocker <[e-mail]>]

On 12/11/2018 9:01 PM, Scott Kitterman wrote:
> On Tuesday, December 11, 2018 08:17:38 PM Dave Crocker wrote:

>> 1.  If the registry is to constrain which public suffix operators 
>> are constrained to assert a default record, then I'll claim that's
>> a false sense of security, given the range of unrelated and even
>> more serious powers a parent domain can exert over a subordinate
>> one.
>> 
>> 2.  If it is to avoid wasting a DNS a query to a record that won't 
>> be there, that's false economy.  Most queries to the registry will
>> fail. And most queries to both the From: domain name and its
>> organizational domain already fail. The incremental cost of a
>> wasted query to the organizational domain's parent is pretty
>> small.
>> 
>> And the cost of creating and running a query-able database that is
>> kept current is high and error-prone (as the existing PSL
>> demonstrates.)
...

> I think your analysis is essentially correct, but I think point 1 is 
> backwards.  Since (in the current draft), based on the registry
> entries, the third level queries will usually not take place. It's
> not that the PSOs are constrained not to publish records (they
> aren't), it's that no one will (should) query for them based on the
> third level test if they aren't in the registry.
> 
> This may seem like a small thing, but I believe it makes all the difference.  
> You are certainly correct that nothing in an RFC can prevent a PSO from 
> publishing such records.  What we can do is give guidance on when not to look 
> at them.

That's a cost-saving line of concern.  My point is that the existing
mechanism already has quite a bit operational inefficiency from queries
that fail, so that adding one more is a minor issue, especially as
against the considerable administrative and operational cost of creating
and running a registry.


> I believe avoiding the privacy implications of the related feedback
> are worth the transactional costs of the registry (but then I would,
> wouldn't I).  I don't think a bad situation justifies making it
> worse.

Sorry but I don't know what privacy implications you are referring to.
I don't even have a guess.

And the draft makes no reference to privacy issues.  Or rather, the 
Privacy Considerations section says the draft doesn't introduce any.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net