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

From: "Brotman, Alexander" <[email-masked]>
Date: Mon, 25 Feb 2019 20:38:22 +0000

Hello,

Stephen and I have spent a bit of time working on a draft to be able to show a relationship between two domains.  We're aware this subject has been covered a few times previously, especially in the DBOUND drafts, but we're hopeful that a more simple approach might be more acceptable.   The secondary domain will create a DNS record that shows a link to a primary domain, and the text should be able to be validated using the public key in a DNS record the primary domain shares.  This is something akin to DKIM, a mechanism that the email world uses to ensure the contents of a message have not been tampered with.

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

We'll request that replies relating to this be sent to the [email-masked] due to the nature of the topic, but it was suggested that we might want to notify a few other lists for their awareness.  Thank you for your participation and comments.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

---

From: Paul Wouters <[email-masked]>
Date: Wed, 27 Feb 2019 09:24:46 -0500 (EST)

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

I've read the draft, and I have my usual complaints.

If we put stuff into the DNS for security decisions, saying "its better
if you use this data when it is DNSSEC signed" is just too weak. We are
splashing TOFU everywhere and putting CT bandaids on it. It's long overdue
that we stop with that. Just require DNSSEC.

And if you require DNSSEC validation, then the solution becomes
much simpler and could be encoded in a single bit, see:

https://tools.ietf.org/html/draft-pwouters-powerbind

Paul

---

From: "Brotman, Alexander" <[email-masked]>
Date: Wed, 27 Feb 2019 15:32:12 +0000

I'm supportive of doing this in other ways, but also understand that DNSSEC is not widely deployed.  I suppose that's ultimately a crutch, though it is the current situation.  With that being said, we thought this would be one reasonable approach to being able to show that relationship.  We could potentially have a non-DNSSEC and DNSSEC method in the same draft, if that's something that might be agreeable?

-----Original Message-----
From: dbound <[email-masked]> On Behalf Of Paul Wouters
Sent: Wednesday, February 27, 2019 9:25 AM
To: Brotman, Alexander <[email-masked]>
Cc: [email-masked]; [email-masked]; Stephen Farrell <[email-masked]>; [email-masked]
Subject: Re: [dbound] [DNSOP] Related Domains By DNS (RDBD) Draft

If we put stuff into the DNS for security decisions, saying "its better if you use this data when it is DNSSEC signed" is just too weak. We are splashing TOFU everywhere and putting CT bandaids on it. It's long overdue that we stop with that. Just require DNSSEC.

And if you require DNSSEC validation, then the solution becomes much simpler and could be encoded in a single bit, see:

Paul

_______________________________________________
dbound mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dbound

---

From: Paul Wouters <[email-masked]>
Date: Wed, 27 Feb 2019 10:48:27 -0500 (EST)

> I've read the draft, and I have my usual complaints.

I scanned this document a bit too fast, with an eye on parent-child
relationships and didn't fully realise this is about relating domains
at different parts in the DNS hierarchy alltogether.

So now I do understand the format and use better. I'm not sure if the
DNS is the best place for this information, but it is not the worst
place either. So in that sense this proposal seems fine.

I do still have a concern that this is using its own signature schemes
embedded in the records instead of relying on DNSSEC. But I guess
that's just the world we live in now.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 27 Feb 2019 10:54:20 -0500 (EST)

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

One more question (and then I promise to walk away from the keyboard for
a while)

How is this data being consumed by the enduser ? It sort of begins
to look like an EV thing. Also, wouldn't attackers just link their
fake domain to another fake domain to get a green looking OKAY?

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Feb 2019 15:57:34 +0000

Hi Paul,

>> I've read the draft, and I have my usual complaints.

Thanks for taking a read!

> at different parts in the DNS hierarchy alltogether.

And even more thanks for reading it twice! It is short,
luckily:-)

Great that you think it's uncrazy.

> place either. So in that sense this proposal seems fine.

Yep. Actually in exchanges with John Levine on the dbound
list, (he was v. reasonably questioning the value of these
new signatures), I myself only copped on that this could
be of some use where the primary has DNSSEC but where the
secondary doesn't, which is maybe interesting.

Those mails are here [1] if someone's interested.

> that's just the world we live in now.

Yep. After both domains have DNSSEC, then this could all be
simpler. Before they do, there may be value in the sigs though
see John's simplification suggestion at [1].

Cheers,
S.

[1] https://mailarchive.ietf.org/arch/msg/dbound/PON1ipCbK_ea67fbyvhUzSfj5og

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Feb 2019 16:14:46 +0000

Hiya,

On 27/02/2019 15:54, Paul Wouters wrote:
> How is this data being consumed by the enduser ? 

Very good question. Sorry for what's likely a longer
answer than you want:-)

Alex and I chatted about that and I think ended up
figuring: a) there are many potential semantics that
could be associated with such a linkage, b) we don't
yet know what'd be useful, but c) no, we are defo
not trying for an EV-like thing and lastly d) we really
want to keep this as simple as possible - given there's
a lot of feature-creep potential here, and that'd likely
be fatal.

My own use-case for this relates more to surveys, where
I'd like to get a hint that two names are related so I
could take that into account. Alex's is more business
like (as you'd expect:-) he'd like to be able to feed
this kind of linkage information into mail processing,
e.g. perhaps to treat some mails as less-likely spam if
he sees a link, compared to if he doesn't (with all the
other mail processing foo that'd clearly be required to
not do that kind of thing stupidly of course). We guess
that there'd be other uses too but finding out if this
is seen as useful enough that people would publish RR's
is part of why we shot out the draft now.

We also considered whether or not to e.g. try to add
some kind of flag to indicate semantics but reckoned we
don't know enough to do that for now.

Cheers,
S.

> It sort of begins

---

From: Tony Finch <[email-masked]>
Date: Wed, 27 Feb 2019 16:26:29 +0000

> that's just the world we live in now.

I wonder if it should instead be a SIG(SOA) where the signer is the
primary domain, but I'm not sure what the other bits of this SIG record
should say. Also, I wasn't around when DNSSEC worked like that, so there
are likely to be all sorts of good reasons why this is not a fun and
enticing prospect.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
no one shall be enslaved by poverty, ignorance, or conformity

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 27 Feb 2019 16:37:32 +0000

> From: DNSOP <[email-masked]> On Behalf Of Stephen Farrell
> Sent: Wednesday, February 27, 2019 11:15 AM
> To: Paul Wouters <[email-masked]>; Brotman, Alexander
> <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [EXTERNAL] Re: [DNSOP] [dbound] Related Domains By DNS (RDBD)
> Draft
>
>
> Hiya,
>
> Very good question. Sorry for what's likely a longer answer than you want:-)
>
> figuring: a) there are many potential semantics that could be associated with
> such a linkage, b) we don't yet know what'd be useful, but c) no, we are defo
> not trying for an EV-like thing and lastly d) we really want to keep this as
> simple as possible - given there's a lot of feature-creep potential here, and
> that'd likely be fatal.
>
> My own use-case for this relates more to surveys, where I'd like to get a hint
> that two names are related so I could take that into account. Alex's is more
> business like (as you'd expect:-) he'd like to be able to feed this kind of
> linkage information into mail processing, e.g. perhaps to treat some mails as
> less-likely spam if he sees a link, compared to if he doesn't (with all the other
> mail processing foo that'd clearly be required to not do that kind of thing
> stupidly of course). We guess that there'd be other uses too but finding out if
> this is seen as useful enough that people would publish RR's is part of why
> we shot out the draft now.
>
> We also considered whether or not to e.g. try to add some kind of flag to
> indicate semantics but reckoned we don't know enough to do that for now.

This might also be useful for IDN variants where some downstream consumer would like to know that two different IDNs are actually "the same". The relationship between variants isn't a parent-child relationship (they're more commonly siblings), but perhaps the concept could be extended to identify sibling relationships, too.

Scott

---

From: Paul Wouters <[email-masked]>
Date: Wed, 27 Feb 2019 11:51:48 -0500

If it is really only a variant, you should just DNAME it to the other domain ?

Sent from mobile device

On Feb 27, 2019, at 11:37, Hollenbeck, Scott <shollenbeck=[email-masked]> wrote:

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

---

From: David Conrad <[email-masked]>
Date: Wed, 27 Feb 2019 18:23:22 +0100

Alexander,

On Feb 27, 2019, at 4:32 PM, Brotman, Alexander <[email-masked]> wrote:
> I'm supportive of doing this in other ways, but also understand that DNSSEC is not widely deployed.

There is a difference between not being deployed and not being turned on.  My impression is that most DNS servers these days support DNSSEC, however it has largely not been enabled.  If you are going to be putting stuff into the DNS for security decisions, you need to protect that stuff and that means turning on DNSSEC.

Regards,
-drc

---

From: "John R. Levine" <[email-masked]>
Date: 27 Feb 2019 12:26:03 -0500

> secondary doesn't, which is maybe interesting.

In that case, the primary can just publish pointers to the secondaries, 
and we're done.

The DKIM-like signatures have an odd model where the primary has enough 
control over its DNS to publish the validation key, and enough to give the 
secondaries signed records for their names they can publish that point 
back to that key, but not enough just to publish the secondaries' names 
directly.  I don't get it.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Ted Lemon <[email-masked]>
Date: Wed, 27 Feb 2019 13:38:46 -0500

> see John's simplification suggestion at [1].

If they don’t have DNSSEC, what’s the point of saying the domains are related anyway?   What are the security properties of such an assertion when the content of the zones can’t be validated?

---

From: "A. Schulze" <[email-masked]>
Date: Wed, 27 Feb 2019 20:50:10 +0100

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

Hello @all,

I read the draft. Interesting idea ...

page 3: s/namess/names/

page 3: "sample TXT record for the parent domain..."
why should the record contain a "s=2018a". Isn't the selector name already defined by the label itself?

6.2. a.com->b.com->c.com->a.com
isn't it better using the example domain? "a.example -> b.example -> c.example -> a.example"

is there a reason that loops only *SHOULD* end after 3 lookups?
SPF for example has a *hard* limit of 10 lookups (https://tools.ietf.org/html/rfc7208#section-4.6.4)

Page 6 / example:
"The published record would be: ..."
I'm missing the label *where* this record would be published.

Just an idea: is this something we could work on during the IETF 104 hackathon?

Andeas

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Feb 2019 19:58:46 +0000

Answering two for the price of one...

On 27/02/2019 17:26, John R. Levine wrote:>> new signatures), I myself
only copped on that this could
> control over its DNS to publish the validation key, and enough to give
> the secondaries signed records for their names they can publish that
> point back to that key, but not enough just to publish the secondaries'
> names directly.  I don't get it.

That could work, but'd mean the primary having to store
all the records and an extra lookup if even if you had the
public key cached. I believe the former could be an issue
if there are many secondaries, at least according to one
chat I had with someone involved with many domains (which
I'm not). I think the design in our -00 is a bit better
than that, but not hugely better and it's ok we can disagree
about it - if this goes somewhere there'll be plenty of
time to thrash it out as we go.

On 27/02/2019 18:38, Ted Lemon wrote:
>> simpler. Before they do, there may be value in the sigs though see 
>> John's simplification suggestion at [1].
> 
> If they don’t have DNSSEC, what’s the point of saying the domains
> are related anyway?   What are the security properties of such an 
> assertion when the content of the zones can’t be validated?

The point of making the assertion would be in the eye of the
beholder. The level of confidence one might have in such an
assertion (without DNSSEC) should of course be lower. But we
do work without DNSSEC for almost everything today so I'm
not convinced "no DNSSEC" => can't be done here. (And again,
the use-cases we've discussed are not high-security ones.)

FWIW, I am a fan of DNSSEC, deploy it for domains I control,
and do consider that despite it's gnarliness it provides
real benefits. But I don't believe we can seriously require
it as a pre-requisite for almost anything today, and nor do
I believe that our proposal, if it goes ahead would by itself
cause people to deploy DNSSEC. So ISTM that making DNSSEC a
MUST-use isn't the right approach in this case.

Cheers,
S.

> 
> 
> 
> _______________________________________________ art mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/art
>

---

From: "Michael J. Sheldon" <[email-masked]>
Date: Wed, 27 Feb 2019 22:19:33 +0000

Section 1:

Current issues #1 says "use TXT or new RR?  (ATB: new RR, but TXT for now)"

Is there a single person here who believes this? Once implemented as
TXT, I give the odds of seeing a specific type record being implemented
as less than zero. Pick one, don't tease.

Section 2:

I am vehemently against adding yet another large TXT record at the apex
of zones. Everybody and their brother wants to jam something there. We
are polluting the apex to such a point that it will no longer be
possible to answer TXT queries via UDP even with EDNS. If you MUST use
TXT, please prefix the name with an application-specific value.

-- 
Michael Sheldon
Dev-DNS Services
GoDaddy.com

---

From: "John Levine" <[email-masked]>
Date: 27 Feb 2019 21:03:32 -0500

In article <[email-masked]> you write:
>I'm not).

Well, OK, if that's an issue you spread the names out like we did with
VBR.  If the primary is foo.com and the secondary is bar.org:

bar.org._same.foo.com. SAME .	; yes, we're a primary for whatever name that was

_same.bar.org. SAME foo.com. ; yes, we're secondary for foo.com.

This makes it somewhat more difficult to scrape all the secondaries
for a primary which may be a feature.

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 Feb 2019 02:17:04 +0000

Hiya,

> for a primary which may be a feature.

Yep, that could work. I still prefer the design in our
-00 though (sorry:-) as in your scheme here foo.com's zone
will have to change with every change in a linkage whereas
in the -00 design, changes are only needed in each of the
bar.org zones that actually do change. (I think the counter
to that might relate to difficulty in synchronising changes
to keys/selectors in our -00 design which can have unexpected
effects as we saw in the case of DKIM and a particular mail
corpus leak in 2016;-).

To be clear: for my purposes I'd be ok with various of the
designs we've been discussing - even if I think some are
better than others, they're nearly equally ok. I think the
main thing is to try keep it simple (as you've been doing)
and to try find out if people might publish such values
(absent which, there's no much point in publishing an RFC).

Cheers,
S.

---

From: "John R Levine" <[email-masked]>
Date: 27 Feb 2019 21:26:01 -0500

> effects as we saw in the case of DKIM and a particular mail

Sure, but pick your poison.  With your scheme you need a mutant DKIM 
signer at the primary and a way to send the result to the secondary.  With 
mine, you just add a record.  I realize that one or the other may be 
easier depending on where an organization's processes are broken but it's 
not obvious to me that the more complex design has an easier process.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly