On November 30, 2018 9:40:33 PM UTC, Zeke Hendrickson <ezeki...@umich.edu>
wrote:
>On Wed, Nov 21, 2018 at 02:37:19AM -0500, Scott Kitterman wrote:
>> While we were discussing making draft-kitterman-dmarc-psd a working
>group
>> item, the main discussion point was about the use of an IANA registry
>to
>> identify participating public suffix domains. I think it would be
>useful to
>> consider what problems we were trying to solve and see if there are
>> alternative approaches that address those requirements.
>>
>> Goals:
>>
>> 1. Minimize additional verifier burden for adding PSD DMARC support.
>
>> Currently it requires consulting a locally stored, infrequently
>changing list
>> and one additional DNS lookup only for participating public suffixes
>when
>> there is no organizational domain DMARC record.
>>
>> 2. Externalize signaling about PSD participation. As discussed in
>the
>> Privacy Considerations (section 4.1), we were concerned about the
>privacy
>> implications of feedback on organizational domain traffic for
>organizational
>> domains that don't participate in DMARC being inappropriately
>captured by
>> public suffix operators. In order to avoid this, we identified
>criteria for
>> which public suffixes PSD DMARC would be appropriate for and require
>an
>> external review to ensure those criteria are met. No solution that's
>in DNS
>> will address this part of the problem.
>
>I feel that restricting the additional PSD check to nonexistent
>organizational domains is the best approach, as it preserves the
>opt-in nature of DMARC, limits privacy concerns, remains very
>straightforward to implement as a verifier, and does not rely on an
>additional list.
RFC 7489 (DMARC) Appendix A.4 mentions that a domain existence test was tried
and abandoned as unreliable. Before reconsidering that kind of approach, it
would be important to understand the limitations that caused it to be discarded
before.
As Kurt mentioned, I don't think it solves the registry problem in any case
because I don't think wide open TLDs like .com ought to be stimulating feedback
on any lower level elements of the DNS tree.
>draft-ietf-dmarc-psd-00 addresses a slightly broader problem space,
>but I feel that adding the ability to get feedback on abuse of
>nonexistent domains is the most needed aspect; treating branded PSDs
>as organizational domains would be better addressed by improving the
>way organizational boundaries are determined.
Currently we have no mechanism at all for that, so I'd be reluctant to abandon
the use case in favor of a non-existent solution.
Also, I think a formal non-existence test would require additional DNS lookups
and might not even be simpler to implement.
Scott K
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
