Re: [DNSOP] Proposal: Whois over DNS

John Bambenek <jcb@bambenekconsulting.com> Tue, 09 July 2019 16:18 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 538EA1206FF for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 09:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.288
X-Spam-Level:
X-Spam-Status: No, score=-4.288 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, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 sNJLUT4wV_lJ for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 09:17:51 -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 EF54F1206EA for <dnsop@ietf.org>; Tue, 9 Jul 2019 09:17:42 -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=izuvhZizu+xVQXfqsQo30xhppVg2Dx666VcKnHCF0d8=; b=VBaa5FwNEK08G+xAhcIPgQleG 9fgJUwq9DyNtykAui8A3eoZXZDkqyWbh0atKwf4UVn4TB/gjHVkfNJEKNvAYj/AseOmgIS++TxlMW qf4GKIJjpXkJBUM85pMah/KSfBX2miFG2+i9Yw1EBR0uoSbhnI05RyGfVPnaMdTWk5n/s=;
Received: from [216.169.1.210] (port=3611 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 1hksoG-0002DV-8P; Tue, 09 Jul 2019 12:17:40 -0400
To: Ted Lemon <mellon@fugue.com>
Cc: Bjarni Rúnar Einarsson <bre@isnic.is>, dnsop@ietf.org
References: <38f1b45c-435d-67d4-b366-623e3866d295@bambenekconsulting.com> <BAEEPhiuJepHAHzp8x4XoDPwyqNoIGHyRzIJmRdb2353@mailpile> <c0c66745-8fa8-9c2d-effc-d7a97332df3c@bambenekconsulting.com> <174B3D2E-488A-44A1-AC46-A8490B2AC760@fugue.com>
From: John Bambenek <jcb@bambenekconsulting.com>
Openpgp: preference=signencrypt
Message-ID: <57344b52-2ad1-d3db-9346-a74ccdb2c347@bambenekconsulting.com>
Date: Tue, 09 Jul 2019 11:17: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: <174B3D2E-488A-44A1-AC46-A8490B2AC760@fugue.com>
Content-Type: multipart/alternative; boundary="------------0D726AC91409A2E5D2D3A5DD"
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/ycUCyXHFMgodIoRkPUwQtnXkfCo>
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 16:18:04 -0000

On 7/9/19 11:09 AM, Ted Lemon wrote:
> On Jul 9, 2019, at 12:03 PM, John Bambenek
> <jcb=40bambenekconsulting.com@dmarc.ietf.org
> <mailto:jcb=40bambenekconsulting.com@dmarc.ietf.org>> wrote:
>> I cannot coerce anything. I represent nothing that represents even a
>> molecule of the network to coerce or enforce anything. I hope incentives
>> will be created, and those may be purely positive incentives (mails more
>> likely to be delivered, etc).
>
> This is why I keep asking you for a clear use case.   What you are
> describing here is a real problem.  The solution to that problem is
> not to publish everyone’s private information in a huge public database.
>
Everyone is not the scope. People who chose to is the scope. Heck,
"everyone" includes people who aren't domain operators also.

Use cases:

- Victim notification of compromised webpages or abuse reports.

- Use in reputational systems to better calibrate security policy to
trust "good" sources and mistrust "bad" sources.

- Aid in investigations, correlate malicious infrastructure, etc.

>> To put your argument in another way, I as someone who protects uses
>> should NOT have information with which I could potentially reliably
>> block malicious individuals could be another way to frame your position.
>> That's a position.
>
> Whether or not you should have this information has no bearing on
> whether it should be in a public database.  There are much better ways
> to solve this problem, which require no privacy violation at all.
>  Just as one example, if I establish mutual trust with everyone I’m
> corresponding with, then we can set up a mechanism whereby any mail
> from a source with which trust has not been established can be dropped
> automatically.   This does not require a public database with my
> personal identifying information.  It can probably even be done in
> such a way that you don’t have a map of who knows whom, although
> that’s a hard problem.  But even if it were done in such a way that it
> gave you, someone with whom I have a business relationship,
> /private/ access to my contact graph, that would be much less bad than
> making all of my personal information public.
>
It would be in a public database in one instance only:

Someone chooses to put it there.

Ok, if there is a better solution, I'm listening. I'm not hear to
mandate a path, I started a discussion. What technical mechanism can be
implemented that scales that can facilitate mutual trust with everyone
an organization corresponds with?

And again, this proposal doesn't require anything and it certainly
doesn't do a proposal for "all your personal information", there are
only four classes of OPTIONAL data: name, email, phone, address. And it
can be role-based information. You could presumably fill all four of
those out validly and expose NO personal information.