IETF Logo Mail Archive

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

"Brotman, Alexander" <Alexander_Brotman@comcast.com> Wed, 27 February 2019 15:32 UTC

Return-Path: <Alexander_Brotman@comcast.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43280130FDB; Wed, 27 Feb 2019 07:32:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiL5m6Bu8eE1; Wed, 27 Feb 2019 07:32:15 -0800 (PST)
Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5725A1200B3; Wed, 27 Feb 2019 07:32:15 -0800 (PST)
X-AuditID: 44571fa7-9f3ff70000021550-f4-5c76ad7e8e4f
Received: from PACDCEX23.cable.comcast.com (dlpemail-wc-2p.cable.comcast.com [24.40.12.145]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 2F.EB.05456.E7DA67C5; Wed, 27 Feb 2019 10:32:14 -0500 (EST)
Received: from PACDCEX19.cable.comcast.com (24.40.1.142) by PACDCEX23.cable.comcast.com (24.40.1.146) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 27 Feb 2019 10:32:12 -0500
Received: from PACDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8304]) by PACDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8304%19]) with mapi id 15.00.1395.000; Wed, 27 Feb 2019 10:32:12 -0500
From: "Brotman, Alexander" <Alexander_Brotman@comcast.com>
To: Paul Wouters <paul@nohats.ca>
CC: "art@ietf.org" <art@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, "dbound@ietf.org" <dbound@ietf.org>
Thread-Topic: [dbound] [DNSOP] Related Domains By DNS (RDBD) Draft
Thread-Index: AdTNSNgC8Q46/YWfTPCiSrkXJ1OYgQBiUEUAAAhZBnA=
Date: Wed, 27 Feb 2019 15:32:12 +0000
Message-ID: <f14544d37a774907a7cc76ab5bdb8b72@PACDCEX19.cable.comcast.com>
References: <5de9ba1c3ae34edb9c7f39e0e9c3b143@PACDCEX19.cable.comcast.com> <alpine.LRH.2.21.1902270920580.8896@bofh.nohats.ca>
In-Reply-To: <alpine.LRH.2.21.1902270920580.8896@bofh.nohats.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [96.114.156.7]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCKsWRmVeSWpSXmKPExsUiocEzUbdubVmMwfqLwhYr7npY7Lp8jd3i 7pvLLBbvb11ispi+9xq7A6vH2u6rbB5Llvxk8vg+jymAOaqB0aYkoyg1scQlNS01rzjVjksB A9gkpablF6W6JhblVAal5qQmYlcGUpmSmpNZllqkj9UYfazmJHQxZcy4t4Ot4Llgxc/fF9ga GI/zdTFyckgImEgsPXiJpYuRi0NIYAeTRPuSnewQzi5Gib2bG1hBqoQETgI513lAbDYBK4m3 /9uZQWwRAUWJSWcegXUzC8xilGi9tQSsQVjAUWLLlo1QRU4SDRunsULYVhJTzx5iA7FZBFQl /hw9wAJi8wp4Sfyat4sJYnMDo8Sb9U/AGjgFHCTm7tsGNohRQEzi+6k1TCA2s4C4xK0n85kg fhCQWLLnPDOELSrx8vE/VgjbQGLr0n0sELaCRM+E6cwQvToSC3Z/YoOwtSWWLXzNDHGEoMTJ mU+g6sUlDh/ZwTqBUWIWknWzkLTPQtI+C0n7AkaWVYw8ZhZ6FuZ6xoZ6hmbmmxiBacclXH75 DsbtszIOMQpwMCrx8KovKosRYk0sK67MPcQowcGsJMIrsBooxJuSWFmVWpQfX1Sak1p8iFGa g0VJnPfirdIYIYH0xJLU7NTUgtQimCwTB6dUA6P847rrSRu+HHWXvX8lbifzwn0Gzx9NnV7k atbCdPPLk0V7plhcm75l7ZRLcgxpWjw3dV6nlW0Rkru4L5RHrfB/r/NeqQXbfY4zCCY3nmO/ c+GewM+Pm66sz96g8uqZ4NNfTv/UFpVL5Gj94+uc8bjN6MvHKf1i698uPHyp4qOLrAOLwLor k2MklViKMxINtZiLihMB3l4CcDcDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/VTXJhawEpm68T01X6AkoGXlhgyA>
Subject: Re: [DNSOP] [dbound] Related Domains By DNS (RDBD) Draft
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2019 15:32:18 -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?

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

-----Original Message-----
From: dbound <dbound-bounces@ietf.org> On Behalf Of Paul Wouters
Sent: Wednesday, February 27, 2019 9:25 AM
To: Brotman, Alexander <Alexander_Brotman@cable.comcast.com>
Cc: art@ietf.org; dnsop@ietf.org; Stephen Farrell <stephen.farrell@cs.tcd.ie>; dbound@ietf.org
Subject: Re: [dbound] [DNSOP] Related Domains By DNS (RDBD) Draft

On Mon, 25 Feb 2019, Brotman, Alexander wrote:

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

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

_______________________________________________
dbound mailing list
dbound@ietf.org
https://www.ietf.org/mailman/listinfo/dbound

v2.23.0 | Report a Bug | By Email