Those are the examples I used, mostly because that’s the world I live in for my day job.
And in agreement with Stephen, we can work to add more clearly defined use cases in the draft. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: Ben Schwartz <bem...@google.com> Sent: Tuesday, March 3, 2020 11:55 PM To: Brotman, Alex <alex_brot...@comcast.com> Cc: dnsop@ietf.org; Stephen Farrell <stephen.farr...@cs.tcd.ie> Subject: Re: [EXTERNAL] Re: [DNSOP] RDBD (Related Domains By DNS) It sounds like you're proposing that this would be used as part of an anti-phishing e-mail filtering system. That seems like a fine use-case, and I would suggest spelling it out precisely in the draft, instead of the current (vague) use cases. I'm still not entirely clear on how this is supposed to work, which is why I would appreciate the worked example. It seems like, in addition to RDBD, your filter also needs some kind of "appears-related" heuristic, and a list of "high-trust" domains, on the theory that one should block messages containing repudiated domains that look similar to a high-trust domain. However, I don't think this is likely to be a reasonable use of the existing rdbd-tags, neither of which amounts to an accusation of phishing per se. (Consider, for example, the entire ".sucks" TLD.) Regardless of the use case, I think a more detailed example would be helpful for understanding what heuristics are needed, and to what extent RDBD would make the use case easier. On Tue, Mar 3, 2020 at 10:09 PM Brotman, Alex <alex_brot...@comcast.com<mailto:alex_brot...@comcast.com>> wrote: From the perspective of messaging anti-abuse, this can help when that department goes to an outside source. If I see “example.com<http://example.com>” and “example-hr.com<http://example-hr.com>”, is there an easy way today to ensure they’re actually related if they’re not registered through the same firm or hosted at the same NS systems? If one can’t definitively determine that, you might decide that they are spam/phishing messages, and treat them more harshly when trying to determine if they are legit/spam. For example, I’m pretty sure that “google.com<http://google.com>” and “google-events.com<http://google-events.com>” aren’t related based on the content of the latter’s website, but if I were to receive an email message from google-events.com<http://google-events.com>, it might not be as easy to tell. As for cousin domains, if you already know that the malicious domain exists, you can assert a negative relationship. If “example.com<http://example.com>” does not know “examp1e.com<http://examp1e.com>” exists, there would be neither a positive or negative relationship asserted, but the lack of a positive (when others are stated positively/negatively), could be used as some signal by the evaluator. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: Ben Schwartz <bem...@google.com<mailto:bem...@google.com>> Sent: Tuesday, March 3, 2020 5:38 PM To: Brotman, Alex <alex_brot...@comcast.com<mailto:alex_brot...@comcast.com>> Cc: dnsop@ietf.org<mailto:dnsop@ietf.org>; Stephen Farrell <stephen.farr...@cs.tcd.ie<mailto:stephen.farr...@cs.tcd.ie>> Subject: [EXTERNAL] Re: [DNSOP] RDBD (Related Domains By DNS) Thanks for the draft. I haven't been following this, and I found it interesting. I would appreciate more fully worked use cases to explain the motivation. What is the use in correlating different domains? How would one use this to prevent "cousin" attacks? On Tue, Mar 3, 2020 at 2:12 PM Brotman, Alex <alex_brot...@comcast.com<mailto:alex_brot...@comcast.com>> wrote: Hello, A while ago, Stephen and I had sent out a few versions of this, and we had some discussions and revisions were made. At the time, discussion waned, however I wanted to pick this up again before the onset of IETF107. https://datatracker.ietf.org/doc/draft-brotman-rdbd/ I've had some folks contact me privately, and I saw an inquiry on another list. There does seem to be some interest, at least in the anti-abuse and research communities, of making this a functional proposition. To recap, the rough idea is that implementers would be able to positively or negatively confirm relationships between domains. In the world of anti-abuse and research, these links are not always obvious. For example, in a large corporation, some teams may go outside acceptable practice and register a domain through another provider. Or it may be that you have international branches that operate on a different TLD, but you may not have registered with all TLDs. In the latter case, being able to both positively and negatively state a relationship could be useful for anti-spam/phishing. Any questions or comments would be greatly appreciated. Thank you. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast _______________________________________________ DNSOP mailing list DNSOP@ietf.org<mailto:DNSOP@ietf.org> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
