Re: [DNSOP] Proposal: Whois over DNS

John Bambenek <jcb@bambenekconsulting.com> Tue, 09 July 2019 21:38 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 3662312006F for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 14:38:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.296
X-Spam-Level:
X-Spam-Status: No, score=-4.296 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, LOTS_OF_MONEY=0.001, MIME_QP_LONG_LINE=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 jn3AbtR3SnIL for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 14:38:35 -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 AE70E120020 for <dnsop@ietf.org>; Tue, 9 Jul 2019 14:38:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bambenekconsulting.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To: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=nd3VRgmVHTNNd5dAOtyS7belSTQRuvGmDOiAnKlxDsc=; b=o0GF69gIbKaxXVvSB6ilGNU71 ZevSgMu3tZI7rBrXwGBMoeCVV4X1O6onJKoipuPujbjTfm+C8Kg8DyAJCD30E24rbJT0/kbe6BdoM ZqbQZHJNjw9YDW3JK4YZ5R7WsVTLtpJcgdG5YTgk0rZ2acw+/YEK6tBIbZDzdIWMw2MoQ=;
Received: from c-67-167-98-187.hsd1.il.comcast.net ([67.167.98.187]:53762 helo=[192.168.11.181]) by chicago.bambenekconsulting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <jcb@bambenekconsulting.com>) id 1hkxol-0001gG-KC; Tue, 09 Jul 2019 17:38:31 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail-A44DDAAD-7C42-4F73-96F4-80AB477023F3"
Mime-Version: 1.0 (1.0)
From: John Bambenek <jcb@bambenekconsulting.com>
X-Mailer: iPhone Mail (16F203)
In-Reply-To: <CAH1iCipN4k+w2N4FO8On5800M43wCQpD8DtC-tezxT45c=ezKg@mail.gmail.com>
Date: Tue, 09 Jul 2019 16:38:30 -0500
Cc: Jim Reid <jim@rfc1035.com>, "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <BC7D3FC5-CFE7-49DD-A8D3-7A1881FBBD11@bambenekconsulting.com>
References: <1CA7BF1B-DF50-443B-9219-55259835FE23@bambenekconsulting.com> <233E0AD8-97FE-466C-9B6C-D7A376031C3B@rfc1035.com> <93244821-6C22-457F-BA06-CF43CA9FD12B@bambenekconsulting.com> <EDE98437-E0B8-4B2E-8AA5-2F6B0079CE8B@hopcount.ca> <0ece2408-a1ec-fa5f-f8d1-ff65572de1ed@bambenekconsulting.com> <866041097.2378.1562689637240@appsuite-gw1.open-xchange.com> <23e86618-610f-8b49-a3bc-4417ebc28efd@bambenekconsulting.com> <F15A6ACF-E246-4D39-8AA3-FC2A49620A7B@rfc1035.com> <6ADDC7FB-3992-4EDC-9A5D-628E0AAA7CB7@bambenekconsulting.com> <CAH1iCipN4k+w2N4FO8On5800M43wCQpD8DtC-tezxT45c=ezKg@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
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/LwzU97icsWcV6pnMBEMML0Z1GCY>
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 21:38:37 -0000

Below

—
John Bambenek

On July 1st, 2019, my DGA feeds are converting to a CC-BY-NC-SA 4.0 license which means commercial use will require a license. Contact sales@bambenekconsulting.com for details

On Jul 9, 2019, at 16:21, Brian Dickson <brian.peter.dickson@gmail.com> wrote:

> 
> 
>> On Tue, Jul 9, 2019 at 2:01 PM John Bambenek <jcb=40bambenekconsulting.com@dmarc.ietf.org> wrote:
>> Below
>> 
>> —
>> John Bambenek
>> 
>> On July 1st, 2019, my DGA feeds are converting to a CC-BY-NC-SA 4.0 license which means commercial use will require a license. Contact sales@bambenekconsulting..com for details
>> 
>> On Jul 9, 2019, at 15:51, Jim Reid <jim@rfc1035.com> wrote:
>> 
>> >> On 9 Jul 2019, at 17:43, John Bambenek <jcb=40bambenekconsulting.com@dmarc.ietf.org> wrote:
>> >> 
>> >> I guess I'm not understanding the risks of people accidentally disclosing what they don't intend to.
>> > 
>> > I suggest you learn more about GDPR. The penalties for non-compliance can hurt - up to 4% of global turnover.
>> > 
>> 
>> No DPA is going to fine me for publishing my email on my dns zone. Not the use of only first person pronouns. No one is talking about anything a third party will do.
>  
>> Only what domain registrants may do if they so choose. 
> 
> That is technically true, only in the cases where the registrant operates their authoritative DNS server.
> 
> What is problematic, is if a registrant's data is published, where the registrant uses a third party DNS hosting provider, and the registrant makes a claim about that not being intentional. The starting point is a "he said, she said" scenario where GDPR essentially reverses the presumption of innocence on the data providers' part.

There is nuance there. For instance, on twitter, I could tweet my phone number. I may want to do that for any number of reasons, but in no way to twitter compel me to do it, require me to do it, or could it be an accident. 

This gets into an implementation question but anyone implementing this as a DNS operator on behalf of others would need to do something to prevent such circumstances. Namely, it can’t be a checkbox, must be free form and accept what the user wants as long a syntactically valid (ie phone number with just numbers). 

Having the third party autopopulate, yes, definitely GDPR issue. 

But the domain I am emailing from now uses a third-party CDN for DNS. I can publish these records and there is no way it could be an accident. 

> 
> Protecting themselves against this kind of claim would require a significant effort by DNS hosting providers, precisely because there would be a liability issue.
> The bar would probably be quite high, for proving that the publication was done by the registrant, including some manner of proof regarding identity. That is a hard problem.
> For little to no perceived benefit, with a lot of development and support (i.e. expense), I don't see this as likely to be taken up by DNS hosting providers.
> 
> And without uptake by DNS hosting providers, there will not likely be any significant uptake at all, IMHO. High relative risk, no reward.
> 

If I were betting, I would bet it won’t be widely adopted. Sure. I think it should be, and I think you overestimate the complexity of doing it legally (social media companies have figured this out). 

But without an actual standard there is nothing to implement and we’re all guessing at adoption. 

>  
>> 
>> There is nothing in this I-D to require publishing anything. There is nothing in this I-D to require if someone publishes that its PII (can use role based accounts). 
> 
> This line of argument resembles that of the NRA regarding gun use, in promoting the interests of weapons manufacturers. 
> No offense intended, but maybe highlighting the real-world benefits rather than minimizing the risks, would be a better approach.
> I don't yet see any benefit for using DNS as the publication point, particularly all the way down in the registrant's zones. 
> 
> Brian
>  
>> 
>> Please read the I-D being proposed. 
>> 
>> The concern is that a standard structure of a DNS TXT record for WHOIS may inspire someone to “accidentally” publish their email in DNS, something they can coincidently do today because absolutely no new functionality is required to make this I-D happen.
>> 
>> The only thing being proposed here is a standard format be which to put contact info (even role based contact info) into a DNS TXT record in a standard format. 
>> 
>> > Some CIOs are learning this the hard way. British Airways got fined $200M+ yesterday and Marriott’s been hit by a $100M+ fine today, both for data breaches which involved due diligence failures covered by GDPR.
>> 
>> These are third parties managing someone else’s data. 
>> > 
>> > Anyone proposing policies or protocols that involve Personal Data really need to take account of the GDPR implications of their proposals and the likely impact on those who will be affected.
>> > 
>> > Hey, what’s this got to do with dnsop? :-)
>> > 
>> 
>> Because the I-D at hand is about DNS TXT records. 
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop