Subject: Re: [dbound] RDBD Questions

From: Stephen Farrell <[email-masked]>
Date: Mon, 8 Jul 2019 17:00:22 +0100

Hiya,

To add to your reading pleasure on I-D cutoff
day, we've updated the draft [1] as described
below. Comments welcome as always.

Cheers,
S.

[1] https://tools.ietf.org/html/draft-brotman-rdbd-02

On 05/06/2019 15:36, Brotman, Alexander wrote:
> Hello all,
> 
> Stephen and I were able to sit down and discuss the feedback that was received during IETF and via the mailing list.  Based on that conversation, we're planning to make the following changes but would be happy to get any feedback before/as we do that.
> 
> 1) A couple of people wanted a method for disavowing a relationship, i.e. making a negative assertion.  We believe we can achieve this by defining another tag within the RDBD RR.
> 2) As part of adding negative assertions, we're proposing that we make it so that any place where you might list a single name today, you could alternatively point to an HTTPS URL that points at a file containing a list of names.  When doing the negative assertion, this'd allow for an easier method to list numerous entries.
> 3) We'll explicitly document that the RDBD record type envisages multi-valued responses just to make it clear that both positive and negative records can be found at the same location.
> 4) We're not sure if there is a preference for the DNSSEC-style RR value we used in the 01 draft, or for the DKIM-style value that was used in the 00 draft. (We will of course stick with a new RRTYPE and not go back to abusing TXT:-) The end result is the same, but the format of the record value may make more sense to some parties in one format or the other.  For the DKIM-style, this is a familiar format to many who have worked with SPF/DKIM/DMARC records.  On the other hand, the DNSSEC-style might be more familiar to those managing the DNS systems. We've not yet decided which we prefer ourselves, so feedback on this is most welcome.
> 
> Thank you again for your feedback.
> 
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy
> Comcast
> 
> _______________________________________________
> dbound mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dbound
>

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 22 Jul 2019 18:57:36 -0400

Hi,

As usual, though I happen to be employed by the Internet Society, I'm
speaking for myself here.

> below. Comments welcome as always.

I've read this.  As you might imagine, I rather like what this draft
is trying to do.  I also like the symmetry with the CDNSKEY trick,
though I'm not sure it's going to work.  Thanks for doing this, in any
case, because I'm happy to see someone trying to solve this problem.

One of the things that I think the draft would benefit from is some
terminological distinctions that I think have long been missing.  I
think this shows up right in the introduction:

   Determining relationships between registered domains can be one of
   the more difficult investigations on the Internet.

In some sense, of course, this is plainly false.  "Is an ancestor of"
and "is a descendent of", in the strict graph-theoretic sense of the
meaning of "relationship", is easy to decide.  All other
relationships, in the DNS, are _from the point of view of the DNS_,
not that interesting.

The problem the draft is trying to address, however, is _not_ a DNS
relationhip.  Instead, it's an attempt to affirm that there is a
_policy_ relationship between two domains.  This is reasonably clear
if you look at the use cases in the bullet list.

I think that some of the conceptial material might be lifted from
https://tools.ietf.org/html/draft-sullivan-dbound-problem-statement-02
or maybe
https://www.ietf.org/archive/id/draft-sullivan-domain-policy-authority-02.txt
or https://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02
(I tried, fruitlessly, more than once, as you can see :) )

One of the potential snags I see in here is a possible trap involving
the nature of domain names.  It's contained in this observation: "RDBD
is intended to declare or disavow a relationship between registered
domains, not individual hostnames."  The problem is, basically, that
inside the DNS there's actually no way to specify that distinction
without querying for a bunch of SOA records, because every valid
domain name is also trivially a valid owner name for an A or AAAA
record and also a valid point for there to be a delegation.  Indeed, a
domain can also be a hostname easily.  (It might be worthwhile having
a look at https://tools.ietf.org/html/rfc8499 to see whether the
terminology aligns really, though I suspect so.  The real problem is
the ambiguity in the relationship between domain names and hostnames.)

I totally do not understand this claim:

   RDBD relationships are uni-directional.  If bi-directional
   relationships exist, then both domains can publish RDBD RRs and
   optionally sign those.

The relationships in question are necessarily policy relationships.
In that sense, it is simply impossible for the relationship to be
unidirectional, because it is a way of the "setting" side of making
claims that are somehow supposed to be satisfied by the "setted" side
of the relationship.  Moreover, whenever you have a domain that
appears to be a relating-domain that makes an assertion about a
putatively related-domain, it seems to me that you need to check at
the related-domain to see whether the putatively related-domain
actually in fact has a repudiating record.

It strikes me that the lookup loop problem in 6.3 happens precisely
because of the unidirectionality of the definition.  That is, if you
had a bidirectional requirement, then it would be effectively
impossible to have the chained loop described because the
bidirectionality would cut that off.  This would also avoid adding the
somewhat arbitrary limit of how many lookups one ought to do.  (I
observe also that this SHOULD in section 6.3 doesn't really comport
with the 2119 meaning of SHOULD, though I'm not one of the bossypants
people about these uses.)

Hope these comments are useful.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Jul 2019 05:52:17 +0100

Hiya,

Thanks for the comments, responses below...

> relationships, in the DNS, are _from the point of view of the DNS_,

True.

> if you look at the use cases in the bullet list.

Well, we're trying to be agnostic as to the semantics of
what the relationship is. The logic being that if we get
the mechanism right, additional tags can be allocated later
when specific semantics are in play. So I'm not sure if
describing that as a policy relationship is quite right.

> (I tried, fruitlessly, more than once, as you can see :) )

I'll re-read those and try steal as and when seems wise:-)

> the ambiguity in the relationship between domain names and hostnames.)

Yeah, that's fair. I think we could lose that statement.

> The relationships in question are necessarily policy relationships.

See above wrt "policy" and semantics.

> actually in fact has a repudiating record.

I'm pretty sure I disagree with you there, though I may be
wrong, and/or it could be our text is confusing. What we
meant by uni-directional was that just because example.ie
claims to be related to example.de doesn't mean that
example.de necessarily makes the same declaration. (It can
of course, but might not.)

Whether some consumer of this information really needs to
check that both sides make commensurate declarations is, I
think, dependent on the semantics of the relationship,
which, again, we want to avoid for now.

> bidirectionality would cut that off.  
I suspect anything with pointers can cause loops, but sure,
whenever we're closer to done, this could be handled.

> This would also avoid adding the

Fair enough. Will take a look at it.

> Hope these comments are useful.

They are thanks,
S.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 23 Jul 2019 01:37:19 -0400

Hi,

Same disclaimer as before.  (Sorry that it gets dull, but we really
want to make sure the ISOC/IETF LLC relationship is a bright line
before we stop.)

> describing that as a policy relationship is quite right.

This is possibly the part that's balling me up, and possibly the place
that I need a better understanding.  I think that inside a protocol P,
there are two things you can state:

	1.  This is how A & B relate inside P; or

	2.  This is how A & B, which are objects of P, relate outside P.

I claim that any operator of P has exactly those two choices, and that
from the point of view of the operator of P everything in (2) amounts
to policy.

For the particular thing that RDBD is doing, the draft approaches this
from the point of view of "things I want to put in the DNS about an
obect of management for the DNS".  From the DNS's point of view,
that's a _policy_ expression, whatever you might think it applies to.
You can be agnostic all day long about semantics, but you are not
changing the semantics of the DNS and therefore inside the protocol
you hope to address, you're expressing policy.

I think this is a very fine thing to do, please note.  I just think
that, given the way DNS works, it has to be symmetrical or you won't
be able to express what you think you can.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Jul 2019 13:50:25 +0100

Hiya,

> want to make sure the ISOC/IETF LLC relationship is a bright line

That's ok. A #include form might work for follow-ups:-)

> from the point of view of the operator of P everything in (2) amounts

I agree rdbd matches case 2.

I think calling that "policy" is maybe not a good plan though
as people seem to generally infer that policy issues are
always extremely weighty matters that require lots and lots of
complex mechanics.

> be able to express what you think you can.

Hmm. Two things I guess: 1) I fully admit my relative ignorance
of DNS, so you may be right, and 2) I still think you're maybe
wrong:-)

If we're dealing with an rdbd tag of 1 (some, unstated, positive
relationship), then I think the rdbd mechanism can still be
uni-directional even if the real-world relationship is not. And
using the mechanism twice, once for each direction, is entirely
possible. So a uni-directional mechanism seems to me to be a
better stake in the ground.

Second, if we're dealing with some other putative tag value, say
with some semantic related to ownership of the real-world entities,
then that's an inherently asymmetric relationship, which again
leads me to think that a uni-directional mechanism might be best.

All that said, you're right that this is a topic to mull over,
and (for this to work out well) we need to address it in some
way that doesn't create big barriers to deployment.

Cheers,
S.