[Doh] Ignore AD (Authentic Data) bit
"Rene 'Renne' Bartsch, B.Sc. Informatics" <ietf@bartschnet.de> Wed, 27 June 2018 12:45 UTC
Return-Path: <ietf@bartschnet.de>
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 443451277C8 for <doh@ietfa.amsl.com>; Wed, 27 Jun 2018 05:45:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bartschnet.de
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 OMl9tfFSEszi for <doh@ietfa.amsl.com>; Wed, 27 Jun 2018 05:45:39 -0700 (PDT)
Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (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 CB4C5127598 for <doh@ietf.org>; Wed, 27 Jun 2018 05:45:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bartschnet.de; s=2018030201; h=Content-Transfer-Encoding:MIME-Version:Date: Message-ID:Subject:From:To:content-disposition; bh=zlJ6WpiI6Vvm99999sowBnrqpqen3WG6O+i2VIOOixM=; b=byBoOJmRrSqTM7cjL1TPnA4+1v XD4umR1w7p/iKbF+avXK5ewA8Rxh/aT7Hjk8cJYGDaSCeX1Cnn5ECjKaaMw646gBE4pfVNrh1N7n3 pCA4g1d/ABnAjCU8Ef6swGelnZR+Ep9wP8y/+a2fI/583W6SadHqq/LEydXtpVbFx5R/MwA9cZSMI o5JHLSYzCt6b0EDQ73MPIU8KDaInrItknasUlxsXXKNFst5RlfE+7xK9Bdx9kfD9VQmjQ8Hl65hJz wegls15Cx02rLgM1Coww++/z+kZmmTwzx53snFLA9AMDWxngZpzoCrbjcrP/nx3WpvhLQLF1ESbz2 0bx7SrSME8TTgCyxH3I/kkJtLr3LVI4BiOMmcV8BKlsPKZGF6UIaqDkMHIuMF8pLiimZuZbPegB+9 yOtMkp9qZN0xp/k8dF6MPxJP/vgmDrrNEzC4qbEixRvo2v32Trrkd6pHYMq+YWLrfWuHIq7a34Y65 rCkLCI88uWkyOtEcjIgzxv9meJXyyHCdUpabJJ3p2MsHeyuP3LF4+oQn9uVNspnNgUOZ+0cdLAUfA NtDQ0Nnwmna73UlHiF+g01jNhIuI5JSYoYrrQ9FQEsU46zST/5d2yh+4ph3H6a24zBzZ8+VOGfJB1 WG/DbUzwJfZUVeLCvZyBSp1pEFsy+uTtPMUXkSgEU=;
Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1fY9pF-0003zr-W0 with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for doh@ietf.org; Wed, 27 Jun 2018 14:45:35 +0200
To: doh@ietf.org
From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <ietf@bartschnet.de>
Message-ID: <01d7c5ff-fd05-d0c8-b243-78b1b5762cad@bartschnet.de>
Date: Wed, 27 Jun 2018 14:45:31 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/mG71fWwRrn-jb5OHru3Q4GqOy2o>
Subject: [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 12:45:42 -0000
Hi, the AD-bit is just a flag forwarded by the DoH-server to the DoH-client. Nobody knows where or by whom DNSSEC-'validation' was done or if someone tampered with the AD bit on the DoH-server or any upstream server/connection. A security chain is only as strong as the weakeast link. To make matters worse router vendors lull users in a false sense of security by advertising DNSSEC support while only passing along the AD-bit instead of doing DNSSEC validation on the router. This undermines the reputation of DNSSEC. In my opinion the AD-bit should never ever have made it into the DNSSEC-RFCs. I suggest to replace the text 'It is the choice of a client to either perform full DNSSEC validation of answers or to trust the DoH server to do DNSSEC validation and inspect the AD (Authentic Data) bit in the returned message to determine whether an answer was authentic or not.' in section '9. Security Considerations' with 'The DNSSEC AD (Authentic Data) bit MUST be ignored by DoH clients to avoid AD bits manipulated on the DoH server, upstream servers or upstream connections.' Regards, Renne
- Re: [Doh] Ignore AD (Authentic Data) bit Ray Bellis
- Re: [Doh] Ignore AD (Authentic Data) bit Andrew Sullivan
- [Doh] Ignore AD (Authentic Data) bit Rene 'Renne' Bartsch, B.Sc. Informatics
- Re: [Doh] Ignore AD (Authentic Data) bit Andrew Sullivan
- Re: [Doh] Ignore AD (Authentic Data) bit Rene 'Renne' Bartsch, B.Sc. Informatics
- Re: [Doh] Ignore AD (Authentic Data) bit Andrew Sullivan
- Re: [Doh] Ignore AD (Authentic Data) bit Ben Schwartz
- Re: [Doh] Ignore AD (Authentic Data) bit Ted Lemon
- Re: [Doh] Ignore AD (Authentic Data) bit Warren Kumari
- Re: [Doh] Ignore AD (Authentic Data) bit Sara Dickinson
- Re: [Doh] Ignore AD (Authentic Data) bit Petr Špaček