Re: [dbound] draft-brotman-rdbd

[Stephen Farrell <[e-mail]>]

Hi Andreas,

Thanks for taking a read. Response below

On 29/03/2019 17:06, A. Schulze wrote:
> Hello,
> 
> I read the draft. In general I like a possibility to express relationships.
> As noted by Warren at the mic, there is also a desire to express "no relation" explicitly.

Yep. Not sure I understand the cardinality issues with that, but
seems like a reasonable request. Will try figure it out before we
shoot out a -02.

> 
> som thoughts/questions:
> 1.
>> We include an optional digital signature mechanism...
> why optional? without any signature wouldn't it possible to any third party to express any relationship?

Optional for simplicity of deployment.

> 
>> RDBD is intended to demonstrate a relationship between registered domains, not individual hostnames.
> 
> where is the border? May publicsufficlist help defining them?

TBH, I'm pretty sure I don't understand this issue well enough myself;-)
From Alex's POV, he's interested in (mail) domains and not hosts, and
that's I think why he added that. From my POV, I take 'em all as names,
so don't feel strongly, other than that I don't want rdbd to be seen as
useless unless it replaces the PSL (it won't).

> 
> 2.1 / 2.2
> as zone apex is likely to be overloaded today, defining something like _drbd.example covering RDBDKEY and RDBD data comes in mind.

I agree with John L's answer here. If he's wrong that a new RRTYPE makes
this a non-issue, I'd be happy to learn why that's the case.

> 
> editorial:
> 1, mention DKIM like mechanisms, but 2.1 introduce to me unexpected "The RDBDKEY RR uses the same registries as DNSKEY for its fields."
> ... confusing

Ack. Will fix.

> 
> 
>> The trailing "." representing the DNS root MUST NOT be included in the to-be-signed data,
>> so a relating-domain value above might be "example.com" but "example.com."
> what's the reason for not making the root explicit?

I figured it'd be more likely that inclusion of the "." in signed-data
would lead to errors. But I wouldn't sweat it, as I'm pretty sure the
input to signing would be likely to change as this proceeds, so we can
figure it out later.

> 
> the current concept I understand as every random domain can express itself as related domain to a relating domain.
> That allow enumeration via passive DNS technics for example without putting any effort in validating signatures.

I'll ponder whether we can make improvements there somehow.

In a chat with someone (sorry, forget whom) in Prague they made
the suggestion to publish a hash of the related name, at least for
cases where one is disavowing a relationship... that may be a
good plan, but I at least need to ponder it more.

> I understand the desire to allow such enumeration but a more privacy friendly version [1],[2] is welcome, too
> And, yes, DNSSEC shouldn't be optional. Re-using existing DNSKEYs may make the signature/validation stuff easier.

I'm afraid I don't agree that DNSSEC can be a requirement here. RDBD
by itself is not sufficiently compelling to cause a DNSSEC deployment.
And DNSSEC is just not sufficiently deployed to make it a requirement.

Cheers,
S.


> 
> Andreas
> 
> [1] https://mailarchive.ietf.org/arch/msg/dbound/cPUM4AKeowvUPQY3wclWQpAKgEE
> [2] https://mailarchive.ietf.org/arch/msg/dbound/tXghAjUAiezkJLA0FlO0Sy__lrQ
> 
> _______________________________________________
> dbound mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dbound
>