Subject: [dbound] draft-brotman-rdbd

From: "A. Schulze" <[email-masked]>
Date: Fri, 29 Mar 2019 18:06:35 +0100

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.

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?

> RDBD is intended to demonstrate a relationship between registered domains, not individual hostnames.

where is the border? May publicsufficlist help defining them?

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.

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

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

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

Andreas

[1] https://mailarchive.ietf.org/arch/msg/dbound/cPUM4AKeowvUPQY3wclWQpAKgEE
[2] https://mailarchive.ietf.org/arch/msg/dbound/tXghAjUAiezkJLA0FlO0Sy__lrQ

---

From: "John R. Levine" <[email-masked]>
Date: 31 Mar 2019 18:29:36 -0400

> why optional? without any signature wouldn't it possible to any third party to express any relationship?

Don't really understand this question, but see my prior messages about the 
threat model.  I have yet to understand what problem the signatures solve, 
that couldn't be addressed more simply by putting records at the relating 
and related domains that point at each other.

> where is the border? May publicsufficlist help defining them?

Presumably one would use the PSL to find the appropriate places to look.

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

Since the records have new rrtypes, I don't understand what you mean by 
"overloaded".  Underscore prefixes are mostly for TXT records and these 
are not TXT records.

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: Stephen Farrell <[email-masked]>
Date: Sun, 31 Mar 2019 23:57:06 +0100

Hi Andreas,

Thanks for taking a read. Response below

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

> why optional? without any signature wouldn't it possible to any third party to express any relationship?

Optional for simplicity of deployment.

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

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

> ... confusing

Ack. Will fix.

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

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

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

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 1 Apr 2019 00:00:54 +0100

Hi John,

On 31/03/2019 23:29, John R. Levine wrote:
> Don't really understand this question, but see my prior messages about
> the threat model.  I have yet to understand what problem the signatures
> solve, that couldn't be addressed more simply by putting records at the
> relating and related domains that point at each other.

Fair enough. I've also yet to understand what's not clear about that,
but happy to try again, using a permutation of earlier words:-)

If the public key is available with integrity (either via DNSSEC for
the relating domain or via caching) then signatures add some evidence
that the relationship is real.

Cheers,
S.

PS: I figure I agree with the rest you wrote below.

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

---

From: "John R. Levine" <[email-masked]>
Date: 31 Mar 2019 21:01:44 -0400

> that the relationship is real.

But if I publish a DNSSEC signed record that says "this other domain is 
related to me" you get exactly the same level of assurance.

What does the extra signature provide that DNSSEC doesn't?  Conversely, if 
it's not DNSSEC signed, publishing a fake "this other domain" record is 
exactly as hard as publishing a fake public key record.

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 1 Apr 2019 02:37:46 +0100

John,

On 01/04/2019 02:01, John R. Levine wrote:
>> If the public key is available with integrity (either via DNSSEC
>> for the relating domain or via caching) then signatures add some
>> evidence that the relationship is real.
> 
> But if I publish a DNSSEC signed record that says "this other domain
> is related to me" you get exactly the same level of assurance.

Disagree. Your "I" there is ambiguous, and I (meaning me,
personally:-) have explained before how that "exactly the
same" is incorrect. (See text marked "*" below for why.)

> 
> What does the extra signature provide that DNSSEC doesn't?

Sigh. I really have explained this. If email is not sufficient to get
that over, then perhaps we can wait 'till we're in the same room again?
I honestly have no clue how you don't understand this. I could totally
accept that you do understand it, but consider it wrong, (in which case
I'd only consider you mistaken,:-) But given your and my history with
e.g. DKIM, I really am extremely surprised that you do not appear to
understand what I'm tying to explain.

But, see the text marked "*" for why.

> Conversely, if it's not DNSSEC signed, publishing a fake "this other
> domain" record is exactly as hard as publishing a fake public key
> record.

"*": For the 3rd or 4th time, and with feeling: Publishing is not the
same as having a relying-party treat a signature differently. As you'll
no doubt have noted, I did say "with integrity" above, which is more
than just "publishing." That kind of integrity for a public key can
be provided via caching, or DNSSEC. Once one has that, then signatures
are not at all the same as if one were to have only freshly read the
public key from the DNS. For example, if a relying-party has seen the
same public key used for a relating domain N times or for N years, and
sees that public key used again, then that relying-party can treat
that differently, compared to a public key just seen now, without any
DNSSEC. DNSSEC, if deployed for the relating domain (not the related
domain), can provide some similar level of assurance about the public
key.

That trust-model for signatures is entirely as was done for DKIM. I
believe you do understand that trust-model for keys. If not, I would
be surprised but happy to explain yet again.

I do hope that is finally clear but suspect it'll not prove to be.
(Whilst remaining surprised that this could be a surprise to you.)
And I'll nonetheless be happy to try explain for a 5th or 6th time;-)

Cheers,
S.

> 
> R's, John
> 
> _______________________________________________ dbound mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dbound
>

---

From: "John R. Levine" <[email-masked]>
Date: 31 Mar 2019 22:00:10 -0400

On Mon, 1 Apr 2019, Stephen Farrell wrote:

> For example, if a relying-party has seen the same public key used for a 
> relating domain N times or for N years, and sees that public key used 
> again, then that relying-party can treat that differently, compared to a 
> public key just seen now, without any DNSSEC. ...

> That trust-model for signatures is entirely as was done for DKIM.

Well, there's the problem -- this is completely different from the trust 
model for DKIM.

For one thing, DKIM associates a key in the DNS with signatures in 
messages.  The DKIM key is public but the message isn't.  In this design, 
both ends are in the DNS and both are public.

More to the point, although I realize that a lot of DKIM signers never 
rotate their keys, that is universally agreed to be bad practice.  I 
rotate my DKIM keys every month, so you'll never see a key record of mine 
for more than about seven weeks (a month plus some slop at each end.)  I 
would be pretty surprised if anyone considered a DKIM key record more 
credible because it had been around for a long time.

Regards,

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 1 Apr 2019 03:04:44 +0100

On 01/04/2019 03:00, John R. Levine wrote:
>> For example, if a relying-party has seen the same public key used for
>> a relating domain N times or for N years, and sees that public key
>> used again, then that relying-party can treat that differently,
>> compared to a public key just seen now, without any DNSSEC. ...
> 

We disagree there. A public key publishe in the DNS, with potential
(though unlikely) assurance via DNSSEC, is the same model for key
management of public keys. If you do see a difference, the I'd be
very happy to understand what difference you see.

> messages.  The DKIM key is public but the message isn't.  In this
> design, both ends are in the DNS and both are public.

That makes no difference here that I can see. How does an RDBD
signature become worse because the signature bits are public?
> rotate my DKIM keys every month, so you'll never see a key record of
> mine for more than about seven weeks (a month plus some slop at each
> end.)  I would be pretty surprised if anyone considered a DKIM key
> record more credible because it had been around for a long time.

Again, that makes no difference. If a key has integrity (for a
relying-party), it does not matter how new nor old a key that is.
What aspect of key rotation do you think is relevant here?

Cheers,
S.

---

From: "John R. Levine" <[email-masked]>
Date: 31 Mar 2019 22:10:28 -0400

> relying-party), it does not matter how new nor old a key that is.

Um, someone sending mail from your address just said a few minutes ago 
that an older key is more credible.

> What aspect of key rotation do you think is relevant here?

Hey, you're the one who said "N years".

Regards,

---

From: "John R. Levine" <[email-masked]>
Date: 31 Mar 2019 22:14:19 -0400

> signature become worse because the signature bits are public?

It doesn't, but since you can inspect DNS records pointing both ways, the 
signature buys you nothing of value.  If you can believe the signature 
record has integrity because whatever, you can believe the same thing 
about a much simpler pointer record.

Regards,

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 1 Apr 2019 03:18:47 +0100

> Hey, you're the one who said "N years".

Perhaps you are willing to entirely ignore the intent of
what I'm saying and only try score pointless points? It
does seem like that from this side TBH, but nonetheless...

I always said "with integrity." Such integrity can be
built up over years if there is no key rotation. Or it can
be provided via DNSSEC independent of RBDB key rotations,
which has more or less the same effect. That is all very
straightforward. And I believe you do already understand
that, so I remain utterly perplexed as to how you could
possibly remain confused.

At this point, it might be a stylish possibility for you
to say "yeah, I was just testing the limits of your own
understanding of your proposed scheme";-)

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 1 Apr 2019 03:23:16 +0100

On 01/04/2019 03:14, John R. Levine wrote:
> 
> It doesn't, but since you can inspect DNS records pointing both ways,
> the signature buys you nothing of value.  

Sorry, but begging the question so blatantly doesn't seem to me
to be useful.

> If you can believe the
> signature record has integrity because whatever, you can believe the
> same thing about a much simpler pointer record.

Wrong. As previously explained.

Your "whatever" above ignores all I said about public keys
known with integrity. And your "the same thing" is not true
on its face, when DNSSEC is not universal.

Really - why persist in this? The only effect of your argument
here seems to be to [maybe cause the rdbd idea to be tainted by
pseudo-controversy - I don't see what that might gain anyone,
you included.

S.

---

From: "John R. Levine" <[email-masked]>
Date: 31 Mar 2019 22:38:50 -0400

> on its face, when DNSSEC is not universal.

No, really, it doesn't.  You're saying the public key is a token that 
people can find credible through a variety of routes, DNSSEC, stable 
publication, whatever.  But exactly the same routes to credibility apply 
to pointer records.

I also note that in practice, there doesn't ever seem to have been a 
spoofing attack on DKIM key records so in practice mail validators always 
accept them as valid.  Mine have DNSSEC signatures but I'm not aware of 
any DKIM software that gives extra points to signed DKIM keys.

I suppose that if there were some very high value application that 
depended on rdbd records there might be more of an incentive to use DNS 
attacks to fake them, but it all seems like a lot of extra work for 
utterly speculative benefits.

Regards,

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 1 Apr 2019 03:44:46 +0100

> utterly speculative benefits.

Questioning the efficacy of rdbd signatures is reasonable but not
at all the same as a claim to not understand 'em.

I agree that the efficacy of these signatures isn't a slam dunk.
The draft says as much. I'd be happy to improve the explanation
in the text wrt that.

But the signatures are optional. So if I'm wrong that they're
useful, then that's ok, you'll be right and they'll not be used.
Equally, if OTOH but unexpectedly, I'm not wrong, then there'll
be a method for signing defined as part of the spec.

What's wrong with that?

Thanks,
S.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 31 Mar 2019 23:51:13 -0400

> be a method for signing defined as part of the spec.

It adds some significant complexity to the design.

If the crypto bits have significant utility, then baking the needed protocol 
elements for smooth key rollover (e.g. for DKIM you use a new selector and 
leave both the old and new keys live for $TIME to allow everything that was in 
process to be received and validated before the old key is removed).  Are 
multiple RDBD and RDBDKEY records allowed per domain?

If not, particularly due to cache misalignment, a smooth key rollover will be 
very hard.

Multiple records per domain would also allow for algorithm agility (publish 
both RSA and Ed25519 for transition as needed).

Libraries implementing RDBD would need more dependencies and be more complex 
to deploy.

My suggestion would be to think hard if it's really needed and if so, then 
make it a MUST.  If not, take it out.  It can be added easily enough later, 
right?

I do think the explanation could be clearer.  I was following along with John 
Levine's argument pretty well.  It took me several scans of the draft to 
realize that the signature (RBDB record) is published by the relating domain 
and the public key (RDBDKEY record) is published by the related domain.  Once 
I realized that, it made sense.  A signed record, to the extent you can't 
spoof both domains simultaneously or nearly so, would give added confidence 
that the related domain agrees that that relationship is valid and not just 
examp1e.com claiming to be related to example.com.

As a more general comment, RFC 8301 is the reference for the minimum key size 
of 1024 bits (RFC 6346 is 512).  Also, it might be worth looking at RFC 8463 
(which added Ed25519 to DKIM) to see if there's guidance on putting Ed25519 
public keys in DNS that can be reused.

Personally, I think I like the crypto bit, but if it's in, I'd like to see it 
be a MUST.  Also, do we really need RSA?  There are plenty of Ed25519 
implementations available.  Personally, I think it's simpler to deal with (and 
the public keys are way smaller, which is nice for DNS).

Scott K