Re: [DNSOP] Proposal: Whois over DNS

Ted Lemon <mellon@fugue.com> Tue, 09 July 2019 15:22 UTC

Return-Path: <mellon@fugue.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 74EC1120675 for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 08:22:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.604
X-Spam-Level:
X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 z4CuKIgXqwyt for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 08:22:01 -0700 (PDT)
Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2F9512065A for <dnsop@ietf.org>; Tue, 9 Jul 2019 08:22:00 -0700 (PDT)
Received: by mail-qt1-x842.google.com with SMTP id d17so20589218qtj.8 for <dnsop@ietf.org>; Tue, 09 Jul 2019 08:22:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=RliF2tYcbb2IjaWyRrz9w2ZGsmqn5UI4s9d1DZraADU=; b=vuuDh1DF8ewNknMIVUezg7ydPdkiIJJ0JNMaIyna1p2fpJsnmGVFGGbfqdGbso8Qi0 xZp1qythDR3yj4fi4ArhkSVRpF9g7iFL7a1M3Kew9novC4lSBwbQKAq2PoCBJQcNDsT1 YN/Vb/cfH+KbzphDWNHmHfEmI8geJOgX/LMds5X6uBdqqjT83DmcWud5+po1f04vX7VQ zb9/mOWCYnkuSQz0noAnXFgGDILq/TQhd4soDjXfXAKKoerQSSPS9Q1ONBZVsSQBoT0b W+gg3voUAqO/CLZYw0JEMZ/xlbGtHJywEfMH1q5Ugs7+izG60xWmaqdKTfj/AAjfW4lG i5hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=RliF2tYcbb2IjaWyRrz9w2ZGsmqn5UI4s9d1DZraADU=; b=NzKAn7nQnt5XilgjSo/7AXF7U1N2yZttcuS0PvpZbwr0QJWhz1FrYLfjZDZJeThjbS CnTzPbIkFmbhYNdu5E7aYGY6Lj9z7QprmPlpC2+d/wGYmDsKlfrKTDriYzCgWGW55aWQ H2BHjnd6PPQt2JzPSvifTtr2A109RFgSuhnc2dqea79YPELMhPDWOeKkjkN8om8nP2gs OGIMFkTqx2lSQe8lT9wZ2WNcTEjLLNUCpXBosJ7s5qdY32Zbd9d18VhSJkzYa6vumva6 KF44WLbaEHI0ORI5L3B6wZBC+VnSgEtXTslPApoG4LlUF6K/SS4ojVg8OfNgcSB+LAWC nMdA==
X-Gm-Message-State: APjAAAXOEjfdNlGTiC/5cenDiSGmnXHpgkj5bdN+8X0KjsJyNfoviOnC 0qwj93Xd47wYOE77ZnDzFTKAlw==
X-Google-Smtp-Source: APXvYqwExvXNPYtrcejnXykFrNqoA5tAoGfsuq/kYVnKWdkl8jSRxktDECB+ttStIOK1BEVkYIHskg==
X-Received: by 2002:ac8:18f0:: with SMTP id o45mr19033404qtk.273.1562685719816; Tue, 09 Jul 2019 08:21:59 -0700 (PDT)
Received: from [192.168.1.103] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id o5sm9101586qkf.10.2019.07.09.08.21.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 08:21:59 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <C4390F20-F2CE-45F7-A3DD-243313FB0E39@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AB4A2947-76A4-44B3-A703-1EE887EDC22D"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 09 Jul 2019 11:21:51 -0400
In-Reply-To: <37daa562-c8a0-ec11-8a3f-ffebfb464d16@bambenekconsulting.com>
Cc: Jim Reid <jim@rfc1035.com>, dnsop@ietf.org
To: John Bambenek <jcb@bambenekconsulting.com>
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>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ob8dnZVkt3vwT3NiM6q37-BiSHo>
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:22:04 -0000

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.

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

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

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

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.