Re: [Doh] Ignore AD (Authentic Data) bit

Andrew Sullivan <ajs@anvilwalrusden.com> Wed, 27 June 2018 16:46 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242D2130DFE for <doh@ietfa.amsl.com>; Wed, 27 Jun 2018 09:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=d1HTejwi; dkim=pass (1024-bit key) header.d=yitter.info header.b=gErLJIOZ
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 VQakM5cvsVIk for <doh@ietfa.amsl.com>; Wed, 27 Jun 2018 09:46:04 -0700 (PDT)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC88130DEE for <doh@ietf.org>; Wed, 27 Jun 2018 09:46:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 5EB5EBE444 for <doh@ietf.org>; Wed, 27 Jun 2018 16:46:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1530117963; bh=O2xl3IZ7+5m+Cd2S7P6+oRQSinfUzj05Ndttus/H3C0=; h=Date:From:To:Subject:References:In-Reply-To:From; b=d1HTejwiRtYBuJ8LuoOVsuiGXLZ0ctUd7UkGHBAL1CpjBDr2d4lG8auVzM+lLKq9Z toQ02Bi9Rx1uj3CfYUk9y1+S3wMFht9sQ9CQtfpxB8ydj+H7XHl/BOADIj+IW230Bh e5OPCPKo69na6nQvjBsQk6P8IkpuumPnCfsF/ed4=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mf67XFHE9BIQ for <doh@ietf.org>; Wed, 27 Jun 2018 16:46:02 +0000 (UTC)
Date: Wed, 27 Jun 2018 12:46:00 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1530117962; bh=O2xl3IZ7+5m+Cd2S7P6+oRQSinfUzj05Ndttus/H3C0=; h=Date:From:To:Subject:References:In-Reply-To:From; b=gErLJIOZdJ+YxMHgHFiVUqrwcjOb4sLODtrZu7uach3WKS1LlqFThEXeWxHB5zVIX yoITrTKSxklGdoU4aJVAumuChaGJfDb70VtUTHgL7rAkH+JidU9rEZr7kbSYc8eYWH OBHhiL59zwH3OPqdf1dxvsbn0umGzgMNCqoCO5ls=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: doh@ietf.org
Message-ID: <20180627164600.GB22421@mx4.yitter.info>
References: <01d7c5ff-fd05-d0c8-b243-78b1b5762cad@bartschnet.de> <20180627131102.GO22421@mx4.yitter.info> <dc4c0697-7996-7ec4-69c5-881867c81def@bellis.me.uk> <CAPt1N1k36UxrDCgaXvbnCrOybdeswBiBv4Wmw8-kBqUdF1pkVA@mail.gmail.com> <20180627161839.GZ22421@mx4.yitter.info> <e5f4f4b4-f4a6-e90f-113c-12aef1c81bc4@bartschnet.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <e5f4f4b4-f4a6-e90f-113c-12aef1c81bc4@bartschnet.de>
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/l6yLcOhClyLubsL6XwLFI2PlnPw>
Subject: Re: [Doh] Ignore AD (Authentic Data) bit
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jun 2018 16:46:07 -0000

On Wed, Jun 27, 2018 at 06:34:47PM +0200, Rene 'Renne' Bartsch, B.Sc. Informatics wrote:

> The fact that e.g. home router vendors define the DSL line and the network
> path to the resolver of the ISP as trusted to print 'DNSSEC' on the retail
> package without having to develop a full DNSSEC implementation for the
> router.

What's new about that?  Why do you trust such a resolver?  People have
always been able to lie about what they're doing -- that's the whole
point of the text in RFC 4035, and why you are in a position to do
validation yourself anyway.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com