IETF Logo Mail Archive

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

Ray Bellis <ray@bellis.me.uk> Wed, 21 August 2019 16:58 UTC

Return-Path: <ray@bellis.me.uk>
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 90899120C95 for <add@ietfa.amsl.com>; Wed, 21 Aug 2019 09:58:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=portfast.net
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 DYBHmH-BjjuR for <add@ietfa.amsl.com>; Wed, 21 Aug 2019 09:58:01 -0700 (PDT)
Received: from mail.portfast.net (mail.portfast.net [IPv6:2a03:9800:20:1::2]) (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 E2EA71201DC for <add@ietf.org>; Wed, 21 Aug 2019 09:58:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=portfast.net; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: 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=jQqH/TXjyLle/sepTPuWNGInQ878NujG581MYkvnFks=; b=c1YR0NhFSzu9dYMbZPy2DArlZD kHsUK913acncCMqKlrgni777m8yNynX9av+m2FH4lbi55gIg7POnVhyPBfAH/fJz8GCERFOcZdzqY wMzN6Ug+oSgle7i9S3qK+BQLDEWyFjX/CVrckbYZcG/cXQGJejX0MYwpppWVcRFHFfCw=;
Received: from [88.212.170.135] (port=58057 helo=Rays-MacBook-Pro.local) by mail.portfast.net ([188.246.200.9]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1i0Tvq-0000ua-Sy (Exim 4.89) for add@ietf.org (return-path <ray@bellis.me.uk>); Wed, 21 Aug 2019 16:57:58 +0000
To: add@ietf.org
References: <A1128702-1E19-4657-9740-E84AE09992F2@piuha.net> <CABcZeBMfOTjq-8hDDoKMtJvfHUA5nC8o60zuk-2Xe-ZhfwriJQ@mail.gmail.com> <766112E1-F532-4C6B-8CA8-A096671E02EE@piuha.net> <CABcZeBO1nqtSOn8hmcC58Ys5rC9=fXLPQhWStgWL0oSfMQ072g@mail.gmail.com>
From: Ray Bellis <ray@bellis.me.uk>
Message-ID: <a250ce7e-db59-8b74-3ac7-9c5d751b1cb8@bellis.me.uk>
Date: Wed, 21 Aug 2019 17:57:57 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBO1nqtSOn8hmcC58Ys5rC9=fXLPQhWStgWL0oSfMQ072g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/teVcMZE6jnw94IbZC6RhRGO0n1c>
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:58:04 -0000


On 21/08/2019 17:31, Eric Rescorla wrote:
> 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.

With respect, the DNS operations community doesn't appear to agree with you.

There are perfectly good ways to protect both the privacy and integrity 
of the DNS that don't require that centralization.

Ray

v2.23.0 | Report a Bug | By Email