Subject: [DNSOP] RDBD (Related Domains By DNS)

From: "Brotman, Alex" <[email-masked]>
Date: Tue, 3 Mar 2020 19:11:32 +0000

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

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 3 Mar 2020 17:38:01 -0500

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 <[email-masked]>
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.
>
>  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.
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: "Brotman, Alex" <[email-masked]>
Date: Wed, 4 Mar 2020 03:09:17 +0000

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.

From: Ben Schwartz <[email-masked]>
Sent: Tuesday, March 3, 2020 5:38 PM
To: Brotman, Alex <[email-masked]>
Cc: [email-masked]; Stephen Farrell <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

_______________________________________________
DNSOP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 3 Mar 2020 23:55:27 -0500

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 <[email-masked]>
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
>
> *From:* Ben Schwartz <[email-masked]>
> *Sent:* Tuesday, March 3, 2020 5:38 PM
> *To:* Brotman, Alex <[email-masked]>
> *Cc:* [email-masked]; Stephen Farrell <[email-masked]>
> *Subject:* [EXTERNAL] Re: [DNSOP] RDBD (Related Domains By DNS)
>
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 4 Mar 2020 09:41:41 +0000

Hiya,

Thanks for taking a read of the draft.

> per se.  (Consider, for example, the entire ".sucks" TLD.)

Tend to agree that new tags are likely needed any time one
wants better-defined semantics. (That's maybe the core of
the design attempt here.)

> RDBD would make the use case easier.

Ack. Will try add something.

Cheers,
S.

---

From: "Brotman, Alex" <[email-masked]>
Date: Wed, 4 Mar 2020 12:58:49 +0000

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.

From: Ben Schwartz <[email-masked]>
Sent: Tuesday, March 3, 2020 11:55 PM
To: Brotman, Alex <[email-masked]>
Cc: [email-masked]; Stephen Farrell <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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.

From: Ben Schwartz <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, March 3, 2020 5:38 PM
To: Brotman, Alex <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Stephen Farrell <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [DNSOP] RDBD (Related Domains By DNS)

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 05 Mar 2020 10:25:33 +1100

> https://datatracker.ietf.org/doc/draft-brotman-rdbd/

As I think I mentioned before, there is similar work going on at higher layers of the stack.  See https://github.com/krgovind/first-party-sets

That work acknowledges a number of things, most critically what policy decisions might be made as a result of these declarations.  The policies that are bound to these declarations could determine the shape of the design.

In that work, the question of whether declarations can be trusted has turned out to be a massive problem.  The relevant policy being contemplated is the sharing of Web state (e.g., cookies).  In that context, there are incentive structures in place that lead to the strong possibility that some entities would willingly declare a "relationship" with others just to circumvent certain aspects of applicable policies.  That in turn means that the design of the system has to take this style of abuse into account.

To me, that indicates that knowing something about the policies that would be applied is not incidental to the work.

Separately, it appears as though there is no ready means of disavowal other than expiration of the records.  Having a means for repudiation of declarations would be good.