Re: [Add] What to do in this potential working group

Eric Rescorla <ekr@rtfm.com> Wed, 21 August 2019 16:31 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C01120C54 for <add@ietfa.amsl.com>; Wed, 21 Aug 2019 09:31:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 OWEuZOF0Lzf2 for <add@ietfa.amsl.com>; Wed, 21 Aug 2019 09:31:48 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 6219D120C55 for <add@ietf.org>; Wed, 21 Aug 2019 09:31:48 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id z17so2772750ljz.0 for <add@ietf.org>; Wed, 21 Aug 2019 09:31:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DFzujBZ/qo0SWSJ+x5QYe0NCre7E55sL5Ti3vUIl7yo=; b=COFD64EVs2VH1sOtjS4WUS3c0xMBX06JiK23UBPQvtEAN2LpO38mZuDhwRl9yIjEQx Xh2HUhHvBm8ZBbU9alom09HwzpQGzxXnrm5UMVfSpFCC2SiJAp+mgur6x28ge5edSE9k XvE52nG2DfBkvzx7PRw5a5QKuVNaxya1DLGWAlkZubuslzE6Ijm8LYYuJmjSxmKwnQYU bL5Xvfn78C8yMbSyMsPG8Urg6fa9B3EZkRGJp5PzCbCTdd1GhWt7kCcYffPqgrGCpvas EVx1R/ABLfFtGdqPAJ52lbjPsZBJnflQqBZJleMS7mulF7V1FRNQdSAEttA0AbiGZays gYAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DFzujBZ/qo0SWSJ+x5QYe0NCre7E55sL5Ti3vUIl7yo=; b=EzD9aF92Ilu1P7RF9Tf8y3+T4CaaBUDExABqqtUyrxNt1w9MV6EG3U1I79SFyFbD9z pdKqgi7AEHZ4iFA/0BQYF9KLkt8644wtFahaqNrn9SzQ1c4Ye+7ixW5WqvlZkNZsFaFP wp90ymEMsGokrz9qiXM95G1QJ+LMv74Jb6JF9CnTdSgMHiXgVzcByKE6QtWtl4GwRhw5 Pb9VK/rZa8nFRU4fQCa/NP//hpGjWM23z0ppJMb1hXJNFlYxml7lubYTcBNzQFk+RTCu PNnizLrx6sGTV43F9az0jNuJCa8UH4olZxzgC6ujR1eUhi/4mAnt9lz0AyVq6n/PT7/X LY7w==
X-Gm-Message-State: APjAAAUN/M72iPrILcU2o9Y5hDIVfTgcvcnMpVnVyNrK9bJNtAZebuXv UlJrV2JP4+nmpxqi/ta6L2r3YIJupAvLN+sSqRF7cw==
X-Google-Smtp-Source: APXvYqw1NuVOD+FAf8hRI+TXPEDdcQFLFlNli9U5jE9u85sRKjQL8TD2ZB1umltHQsov7IA6edsTmC12KOf20SgpdNc=
X-Received: by 2002:a2e:9acf:: with SMTP id p15mr19669731ljj.13.1566405106383; Wed, 21 Aug 2019 09:31:46 -0700 (PDT)
MIME-Version: 1.0
References: <A1128702-1E19-4657-9740-E84AE09992F2@piuha.net> <CABcZeBMfOTjq-8hDDoKMtJvfHUA5nC8o60zuk-2Xe-ZhfwriJQ@mail.gmail.com> <766112E1-F532-4C6B-8CA8-A096671E02EE@piuha.net>
In-Reply-To: <766112E1-F532-4C6B-8CA8-A096671E02EE@piuha.net>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 21 Aug 2019 17:31:10 +0100
Message-ID: <CABcZeBO1nqtSOn8hmcC58Ys5rC9=fXLPQhWStgWL0oSfMQ072g@mail.gmail.com>
To: Jari Arkko <jari.arkko@piuha.net>
Cc: ADD Mailing list <add@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f0cef10590a31b14"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/mmcaQsm5vOqJTQO6zhWO9NqiNaQ>
Subject: Re: [Add] What to do in this potential working group
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Aug 2019 16:31:51 -0000

Jari,

I understand that this is your opinion and the argument you re making but I
can't say I agree with the overall assessment you are making.

We have a situation now where the DNS is tragically insecure and nonprivate
-- and not really that decentralized -- and we have an opportunity ti make
it more secure at the cost of making it more centralized. In this instance,
I think that's a tradeoff worth considering, while also looking for ways to
minimize centralization.

-Ekr


On Wed, Aug 21, 2019 at 11:55 AM Jari Arkko <jari.arkko@piuha.net> wrote:

> Ekr,
>
> I fully realise that there will be differences of viewpoints when it comes
> to the trustworthiness of individual DNS service providers.
>
> But I was trying to make a different point. While we may disagree which
> provider I’d like to use for the DNS service, I think it would be quite
> reasonable for us to agree that if all of us put our all our queries in one
> place (whatever that is) that this causes severe problems:
>
> - That place becomes immensely valuable from a commercial data mining
> perspective. There’s a risk that it will at least at some point be used for
> data mining, despite whatever the intentions of the people who set this
> system up now is.
>
> - That place becomes immensely interesting to for governments to tap.
> There’s a risk that this tapping is either already happening or will be
> happening going forward, despite best intentions of the people who set it
> up or who manage it.
>
> - That places becomes critical infrastructure and a weak point that we do
> not need in the Internet.
>
> As a result, I would like to suggest that the IETF actually concludes the
> above and recommends against this practice.
>
> For whatever it is worth, I can understand some motivations for doing
> something like this e.g. in browsers. Some good reasons and potentially
> also some not so good reasons. But even with that background, it is
> difficult for me to imagine a worse act for the Internet than making
> browsers call home for every action of the user. The privacy impacts for
> the users are unimaginably bad.
>
> A few years ago we realised that surveillance organisations were looking
> at people's traffic, and we managed to change the Internet to protect this
> traffic with cryptographic means. I think it is to think about the next
> step, and ensure that we don’t create an Internet architecture that puts
> everyone’s data at central location.
>
> Obviously, encrypted DNS is still hugely important, as are global DNS
> services. However, the deployment model of using one (or a small number of)
> providers is just wrong. That would be fixable.
>
> Jari
>
>