Re: [DNSOP] Proposal: Whois over DNS

John Bambenek <jcb@bambenekconsulting.com> Tue, 09 July 2019 14:45 UTC

Return-Path: <jcb@bambenekconsulting.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 423A5120172 for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 07:45:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level:
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bambenekconsulting.com
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 H8GHGCB828cR for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 07:45:14 -0700 (PDT)
Received: from chicago.bambenekconsulting.com (chicago.bambenekconsulting.com [99.198.96.122]) (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 C4C53120170 for <dnsop@ietf.org>; Tue, 9 Jul 2019 07:45:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bambenekconsulting.com; s=default; h=Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NnsCM1aJn1FMXPLGVq8tEG8EcdUu+8C2GFnr+/YTXvw=; b=ZOAg6P/fb21dbQkz19MRf1Hs3 NJHX2g+i3kJEkECAl95kqachj7Wib2TjEYVe4OEDbh0W8Z/vJkU07ptlr1WvrPHFD0iRl2QuLDDUZ VB8TbVQXUMadI7r6KiDXWKHdd5/MMcEy36f2MQDY4rMAKHru1auoJ+2tnx3WFuXM4rusE=;
Received: from [216.169.1.210] (port=22520 helo=jcb.local) by chicago.bambenekconsulting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <jcb@bambenekconsulting.com>) id 1hkrMi-0000BT-7j; Tue, 09 Jul 2019 10:45:08 -0400
To: Ted Lemon <mellon@fugue.com>
Cc: Jim Reid <jim@rfc1035.com>, dnsop@ietf.org
References: <1CA7BF1B-DF50-443B-9219-55259835FE23@bambenekconsulting.com> <233E0AD8-97FE-466C-9B6C-D7A376031C3B@rfc1035.com> <93244821-6C22-457F-BA06-CF43CA9FD12B@bambenekconsulting.com> <F45666C7-181A-4853-897E-40D5C0EA972B@fugue.com>
From: John Bambenek <jcb@bambenekconsulting.com>
Openpgp: preference=signencrypt
Message-ID: <37daa562-c8a0-ec11-8a3f-ffebfb464d16@bambenekconsulting.com>
Date: Tue, 09 Jul 2019 09:45:05 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <F45666C7-181A-4853-897E-40D5C0EA972B@fugue.com>
Content-Type: multipart/alternative; boundary="------------2BDF1A702B5A70AEAD6AA214"
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - chicago.bambenekconsulting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bambenekconsulting.com
X-Get-Message-Sender-Via: chicago.bambenekconsulting.com: authenticated_id: jcb@bambenekconsulting.com
X-Authenticated-Sender: chicago.bambenekconsulting.com: jcb@bambenekconsulting.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2RI3KqVE8vbbiD-3qaYtPLBiE7Q>
Subject: Re: [DNSOP] Proposal: Whois over DNS
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: Tue, 09 Jul 2019 14:45:19 -0000

Below

On 7/9/19 9:28 AM, Ted Lemon wrote:
> On Jul 9, 2019, at 10:07 AM, John Bambenek
> <jcb=40bambenekconsulting.com@dmarc.ietf.org
> <mailto:jcb=40bambenekconsulting.com@dmarc.ietf.org>> wrote:
>> But ICANN won’t allow such a system with meaningful data, so here we
>> are. 
>
> The question you should be asking is “why not?”   The answer is that
> nobody whose info you need will publish it, because the info you need
> is from people who are engaging in misfeasance or malfeasance.  The
> people who will publish accurate information here are likely naive, so
> you’ve really just created a vuln that bad actors can exploit.

Why ICANN won't? The answer is not that altruistic.

If there are incentives they will, yes, wide spread adoption is a
problem, but define accurate? Role-based accounts are fine here (some of
which, I believe are codified in RFCs already). If you'd like, I can get
you the anti-spam people to chime in on their thoughts about how much
abuse would happen compared to how much anti-abuse would be facilitated
given adoption.

> You can’t use the fact that no information, or false information, is
> provided as a basis for seeking out bad actors, because any sensible
> person will not put their information in this database unless they
> have to to get something they need.  If they have to to get something
> they need, they will likely put in false information, because they
> have no legal obligation to do otherwise, and putting in correct
> information would not be in their interests.   So all you’ve done here
> is create two attack surfaces.
>
I most certainly can and do use no information and false information for
making policy decisions. In fact, so do you and everyone here, every
day. Would you give you credit card information over the phone when
receiving a call with no caller ID?
> The first attack is against people who are naive: you now have
> personal information about them that they shouldn’t have given you.  
> The second attack is that you can use the fact that someone posts
> false information, or doesn’t provide information, as a pretext for
> investigating them.
>
You're making an assumption that people SHOULDN'T ever give contact
information. That's not true. Every business puts their contact
information their website. They WANT to be contact. Individuals often
will do the same. On twitter, journalists routinely put their phone numbers.

As far as pretext for "investigating people", as long as I break no
laws, I can't investigate anyone for anything I want at any time I want
for any reason I want. So can you. But that's not the question here.
Voluntary interconnection is. I can deny people access to my resource
for any reason I want.

> If you genuinely think this is worth doing, please come up with a
> real-world use case that meets the following three criteria:
>
>   * It would be in my interest to put information about myself in this
>     database
>
You'd want me (or others) to let you know about compromises, for one.
DMARC does this already, in a sense. I get email reports about potential
abuse of my domain and spoofing emails. To do this, it needs an email. I
get something. But wide-spread adoption is the risk, I don't make any
illusions of that.
>
>   * That information would be useful to you, or to someone specific
>     whom you can identify
>
I can provide lots of use cases and provide others who will attest to
the same. Victim notification, correlation of domains and resources,
investigations, generating reputational data...


>   * My participation in, or non-participation in, this mechanism is
>     entirely voluntary, and can’t be used against me
>
There is no protocol, communication, human endeavor where this will be
every true as far as "not used against me". DNS records is entirely
voluntary now. You control what you put or don't put in there, no one is
changing that. But using it against you or not, someone could use the
fact you are running an IIS web server against you.
>
> You haven’t done that yet.  If this depends on people acting against
> their own interests, we shouldn’t publish it.  If it solves a paper
> problem but isn’t actually useful, we shouldn’t publish it.  It needs
> to solve a real problem in a way that is ethical.   I don’t think it does.
Exactly what ethical standard do you claim is violated here? And if the
answer is that you have some unfettered right to access my network
resources, that is simply false.