Re: [DNSOP] Proposal: Whois over DNS

John Bambenek <jcb@bambenekconsulting.com> Tue, 09 July 2019 15:42 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 25DBC1201A0 for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 08:42:16 -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 E38w2JAoU_KY for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 08:42:12 -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 16ACF1206F3 for <dnsop@ietf.org>; Tue, 9 Jul 2019 08:41:43 -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:To:Subject:Sender:Reply-To:Cc: 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=qddh9SWDIW1cyo9HxHtzS+SWos3AVjJwfQJGf3wFGUU=; b=aU2Marr9yYvEdsR7VzXQaE2mD L/458Mod2PbvC2mb34HjuURr3+7pgMngF1nxvo7AwmEGwqTQuPfIsAnjnpLMlaPLr9fhGK7s3W+So JDXeoniZnIM8B1JZ48NkQlK6H6fVWNyNbrVX/JGG9WVlDkEC2394J5qCo0hJyJvZbU5oY=;
Received: from [216.169.1.210] (port=9138 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 1hksFR-0001Kj-Dl for dnsop@ietf.org; Tue, 09 Jul 2019 11:41:41 -0400
To: 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> <37daa562-c8a0-ec11-8a3f-ffebfb464d16@bambenekconsulting.com> <C4390F20-F2CE-45F7-A3DD-243313FB0E39@fugue.com>
From: John Bambenek <jcb@bambenekconsulting.com>
Openpgp: preference=signencrypt
Message-ID: <884b1e64-7ffb-a793-c15e-480f765a0044@bambenekconsulting.com>
Date: Tue, 09 Jul 2019 10:41:39 -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: <C4390F20-F2CE-45F7-A3DD-243313FB0E39@fugue.com>
Content-Type: multipart/alternative; boundary="------------14CAE9AAAE49EE209A1FF04E"
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/Aqq0PQoRR9VIyhLGF-NrCu-9Czg>
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 15:42:16 -0000

Not intended to debate, per se.

On 7/9/19 10:21 AM, Ted Lemon wrote:
> As far as I can tell, you are deflecting my serious concerns rather
> than responding to them.   I’m asking you to describe an actual
> situation where the information you want us to publish would (a) be
> published and (b) /actually work/ as a means of notifying some real
> person of something, or prosecuting some real crime.  I’m going to
> respond to what you’ve said to point out that it’s not serious, but I
> encourage you not to debate these points with me.  If your goal is
> actually to publish this draft, the right thing to do is come up with
> some good arguments why the IETF should publish it, not to get into a
> debate over details with me.
>
> You respond:
>> 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?
>
> Caller ID is always presumptively forged.  If you actually care about
> not being phished, you should never under any circumstances provide
> your credit card information over the phone if you didn’t initiate the
> phone call.   You shouldn’t even do it then, since telephone
> conversations aren’t encrypted end-to-end.
I'd agree its preemptively forged. Then pick another example. If someone
came up to you on the street and demanded to see identification, you'd
say no. If they were wearing a police uniform and have a badge, you
might say yes (varies between jurisdictions).
>
>> 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.
>>
> This isn’t actually true.  People who want anonymous contact do in
> fact publish information that people can use to contact them
> anonymously, which may be a phone number.   It’s also a straw man.
>  I’m not saying people shouldn’t ever give contact information.  I’m
> saying that people shouldn’t be held hostage in such a way that they
> are forced to _publish_ personal information in order to get services.
No one is holding anything hostage, I guess that's the thing I genuinely
don't get. Individuals are free to publish or communicate how they see
fit. I'm free to reject said communication. It's the other side of the
same coin. No one is forcing anything. If this proposal was universally
implemented, there still would be no force or hostage taking. On one
hand, I'm being told to show incentives, on the other told that such
incentives are coercive. I can't do both.
>>
>> 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.
>>
> Repressive regimes often use pretexts to justify their repressive
> activities.   It is to this that I am referring when I talk about this
> as an attack surface.  Maybe you never engage in improper policing,
> but we can’t assume that this is true everywhere where DNS is used.
I'm a private sector actor, improper policing is criminal. I can't
forsee, however, how a repressive regime could use a phone number in a
DNS record to commit human rights violations.
>>
>> 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.
>
> There is no way in the world that I would ever publish my email
> address as a way to get notifications of compromise.  Not merely for
> privacy reasons, but because the spam rate on that email address would
> be astronomical, and so I’d never see them.
Then don't, that's fine.
>
>> 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…
>>
> These are nearly all examples of ways this information will be used
> against me.  If you think victim notification is a good use case, can
> you describe in detail how that would work?

It's voluntary, if you don't want it, you won't get it. But there are
millions of websites compromised on the internet right now. We can only
clean them either if hosting providers just go in and do it (assuming
they have access), or somehow contact you in a low cost way and getting
you to do it. There exists no easy programmatic way to do this unless
the hosting providers want to get into that business, so the use case
doesn't really exist today.

That being said, the sticking point is "used against you". Anything you
do can be used against you online in deciding whether or not I want to
accept your packets. People block entire countries. That is their right
and how the internet was designed to work. I don't intend to deflect, I
intend to say I believe such a position runs counter to a fundamental
design principle of the internet.

I'd like information, for instance, to accurate and narrowly block bad
providers. In the absence of that data, all I have is provider
reputation. For instance, if you have a .pw or .tk TLD, you're just
blocked. You may be innocent, but if I can't specifically block, I have
to generally block, which means innocent people get dragged in. The
alternative is to not block and allow my constituents to more likely be
victims.

>> 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.
>>
> It’s true that whenever I communicate with anyone, I create a risk for
> myself.  So doesn’t it make sense that I would want to control with
> whom I communicate, rather than broadcasting?
If you are e-mailing me, connecting to my webserver, etc, you want to
communicate with me... should I not have information with which to make
a decision to decide if that's ok? If the answer to this is no, then we
have an irreconcilable philosophical difference and that's ok, I just
disagree and there isn't much middle ground to be had there.
>> 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.
>
> That’s an interesting response, which suggests that you have a use
> case in mind.  The use case you have in mind is that you will deny
> service to people who do not publish this information.  This is
> exactly the attack surface I was describing earlier, and you’ve just
> said that you intend to use this attack.
More accurately, I will score it as part of one of many reputational
indicators if and only if a critical mass of adoption takes place for
the VERY small portion of the internet I have a say on. I'm not Google,
I have no power over even a rounding error of the overall network space.
>
> Of course it’s your right to deny service to people who don’t identify
> themselves to you.  If you want to do that, the way you do that is by
> establishing a business relationship with them and refusing service to
> people with whom you have no business relationship.  It is not by
> creating a huge database of personal information accessible to
> everyone, and demanding that they publish their information in  this
> database.

You assume I'm going to create a huge database, I am not. I would
envision doing something like if you send me email, try to connect, etc,
there is a DNS query for this information, much like there are queries
for DBLs, SPF et al, and score it in real time.

Or if doing abuse reporting, just programmatically look who an email and
then email whatever is given (assuming syntactically valid).

>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop