[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