Re: [DNSOP] [EXTERNAL] Re: RDBD (Related Domains By DNS)

[Ben Schwartz <[e-mail]>]

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

> From the perspective of messaging anti-abuse, this can help when that
> department goes to an outside source.  If I see “example.com” and “
> 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” and “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, 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” does not know “
> 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 <[e-mail]>
> *Sent:* Tuesday, March 3, 2020 5:38 PM
> *To:* Brotman, Alex <[e-mail]>
> *Cc:* [e-mail]; Stephen Farrell <[e-mail]>
> *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 <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>