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

[Martin Thomson]

On Wed, Mar 4, 2020, at 06:11, Brotman, Alex wrote:
> 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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP at IETF 107: call for agenda items and key dates

[Tim Wicinski]

The chairs would like to remind everyone that the Draft submission cutoff
date is this coming Monday, March 9th at 23:59 UTC.

Also, if authors would like agenda time, please drop us a note sooner
rather than later.  Currently, the list of agenda requests can
be seen here:
https://github.com/DNSOP/wg-materials/tree/master/dnsop-ietf107

thanks
Tim for Suzanne and Benno

On Tue, Feb 11, 2020 at 10:25 AM Suzanne Woolf 
wrote:

> Hi,
>
> We’re a few weeks away from IETF 107 in Vancouver, BC, so your chairs are
> starting to put together the DNSOP meeting.
>
> First, this note is our first call for agenda items. Send your requests to
> dnsop-cha...@ietf.org.
>
> The chairs will be reaching out to some draft authors about updates and
> open discussion items so we can use f2f meeting time to resolve issues and
> make decisions about advancing them (adoption, WGLC, etc.) But if you’ve
> got a draft that the WG is discussing or you’d like the WG to discuss,
> don’t be shy!
>
> The drafts deadline for Vancouver is 9 March.
>
> We only have a couple of days after the drafts deadline to post the WG
> agenda, so please: if you want your draft on the WG agenda, try to submit
> it early enough that the WG has time to start discussing it and we’ve got a
> little bit of time to gauge interest and direction.
>
> A few key dates (the full list is at:
> https://datatracker.ietf.org/meeting/107/important-dates/)
>
> 2020-02-28 (Friday): Final agenda to be published.
> 2020-03-09 (Monday): Internet Draft submission cut-off (for all drafts,
> including -00) by UTC 23:59. Upload using the ID Submission Tool.
> 2020-03-11 (Wednesday): Draft Working Group agendas due by UTC 23:59.
> 2020-03-16 (Monday): Revised Working Group agendas due by UTC 23:59.
>
>
> Thanks and see you in Vancouver,
>
> Suzanne, Tim, and Benno
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brotman, Alex]

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 
Sent: Tuesday, March 3, 2020 11:55 PM
To: Brotman, Alex 
Cc: dnsop@ietf.org; Stephen Farrell 
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 
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” 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 mailto:bem...@google.com>>
Sent: Tuesday, March 3, 2020 5:38 PM
To: Brotman, Alex mailto:alex_brot...@comcast.com>>
Cc: dnsop@ietf.org; Stephen Farrell 
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 
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
https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org

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

[Stephen Farrell]

Hiya,

Thanks for taking a read of the draft.

On 04/03/2020 04:55, Ben Schwartz wrote:
> 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.)

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.)

> 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.

Ack. Will try add something.

Cheers,
S.



0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop