Subject: [dbound] RDBD 01 Comments

From: "Brotman, Alexander" <[email-masked]>
Date: Wed, 20 Mar 2019 12:30:59 +0000

Hello folks,

Stephen and I are still looking for additional comments on the newer revision of RDBD [1].  We'd really like to work with everyone to move this forward if possible.  Additionally, he and I should both be in Prague next week if you'd like to have some in-person discussions.

Thank you for your time

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

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

---

From: "John Levine" <[email-masked]>
Date: 20 Mar 2019 14:03:41 -0400

In article <[email-masked]> you write:
>Hello folks,
>
>Stephen and I are still looking for additional comments on the newer revision of RDBD [1].  We'd really
>like to work with everyone to move this forward if possible.  Additionally, he and I should both be in
>Prague next week if you'd like to have some in-person discussions.
>
>Thank you for your time
>

Hm.  I see that instead of DKIM-like signatures, now it's DNSSEC-like signatures.

But I still have the same question: what advantage does all of this
crypto stuff provide compared to a much simpler design where the two
domains just have records that point at each other, like a cut down
version of Andrew's SOPA?

One difference is that you can't tell by looking at the
primary/relating domain what its secondary/related domains are.  I can't tell if that's
a bug or a feature.

---

From: "Brotman, Alexander" <[email-masked]>
Date: Fri, 22 Mar 2019 13:01:54 +0000

The original intent was a providing a bit more of a hurdle to falsifying responses.  I didn't think we could realistically rely on DNSSEC as a requirement (I'm imagining a situation where we have DNSSEC, and someone goes off to Route53 to host a domain where DNSSEC is not supported last I knew), so was hoping this would provide a bit more of a loose assurance that this relationship is intentional.

> -----Original Message-----
> From: John Levine <[email-masked]>
> Sent: Wednesday, March 20, 2019 2:04 PM
> To: [email-masked]
> Cc: Brotman, Alexander <[email-masked]>
> Subject: [EXTERNAL] Re: [dbound] RDBD 01 Comments
> 
> In article
> <[email-masked]> you
> write:
> >Hello folks,
> >
> >Stephen and I are still looking for additional comments on the newer
> >revision of RDBD [1].  We'd really like to work with everyone to move
> >this forward if possible.  Additionally, he and I should both be in Prague next
> week if you'd like to have some in-person discussions.
> >
> >Thank you for your time
> >
> But I still have the same question: what advantage does all of this crypto stuff
> provide compared to a much simpler design where the two domains just
> have records that point at each other, like a cut down version of Andrew's
> SOPA?
> 
> One difference is that you can't tell by looking at the primary/relating domain
> what its secondary/related domains are.  I can't tell if that's a bug or a
> feature.

---

From: Grant Taylor <[email-masked]>
Date: Fri, 22 Mar 2019 09:22:11 -0600

On 3/22/19 7:01 AM, Brotman, Alexander wrote:
> The original intent was a providing a bit more of a hurdle to falsifying 
> responses.

I need to re-read things, but I don't recall why anything needs to be 
complex.  Why can't DomainA.example publish a (simple) record stating 
that it asserts a relationship with DomainB.example.  Ideally, vice versa.

> I didn't think we could realistically rely on DNSSEC as a requirement 
> (I'm imagining a situation where we have DNSSEC, and someone goes off 
> to Route53 to host a domain where DNSSEC is not supported last I knew),

IMHO, more and more things significantly benefit from (if not actually 
need) DNSSEC.  As such, I think we should quite coddling things that 
don't support DNSSEC.  Especially when we are designing things for the 
future.  Design for what we want.  At least unless there is a 
significant reason to not use something like DNSSEC.

Also, I do believe that if enough people want to use technologies that 
need DNSSEC, they can exert enough market pressure to get Route53 (et 
al.) to support DNSSEC.

-- 
Grant. . . .
unix || die

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 22 Mar 2019 15:29:39 +0000

Hiya,

On 22/03/2019 15:22, Grant Taylor wrote:
>> The original intent was a providing a bit more of a hurdle to
>> falsifying responses.
> 

Just a clarification: In this version, they can. The signature is
optional in the -01 version. (I may have mucked up how to describe
that for a new RRTYPE of course;-)

Cheers,
S.

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

---

From: "John R Levine" <[email-masked]>
Date: 22 Mar 2019 11:35:32 -0400

> responses.  I didn't think we could realistically rely on DNSSEC as a 
> requirement (I'm imagining a situation where we have DNSSEC, and someone 
> goes off to Route53 to host a domain where DNSSEC is not supported last 
> I knew), so was hoping this would provide a bit more of a loose 
> assurance that this relationship is intentional.

I still don't get it.  If you're the primary and you have DNSSEC, you can 
with great security publish pointers to all of the secondaries, no extra 
crypto required.  If you're a primary and you don't have DNSSEC, a bad guy 
can with some effort fake a key record and you lose anyway.  Faking a 
primary->secondary pointer or faking a key record are equally hard or 
easy.

Perhaps it would be helpful to make a chart for situations where the 
primary or secondary are and aren't signed, and are and aren't attacked 
and see which (if any) boxes have interesting different outcomes.

R's,
John

>> what its secondary/related domains are.  I can't tell if that's a bug or a

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