Re: [Driu] [Ext] How to describe various flavors of DNS resolvers

Philip Homburg <pch-ietf-driu@u-1.phicoh.com> Tue, 15 May 2018 17:33 UTC

Return-Path: <pch-bCE2691D2@u-1.phicoh.com>
X-Original-To: driu@ietfa.amsl.com
Delivered-To: driu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3F412D944 for <driu@ietfa.amsl.com>; Tue, 15 May 2018 10:33:39 -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] autolearn=ham autolearn_force=no
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 7lkYkb0zW0lZ for <driu@ietfa.amsl.com>; Tue, 15 May 2018 10:33:32 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 77F54126C25 for <driu@ietf.org>; Tue, 15 May 2018 10:33:29 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1fIdpG-0000FGC; Tue, 15 May 2018 19:33:26 +0200
Message-Id: <m1fIdpG-0000FGC@stereo.hq.phicoh.net>
To: driu@ietf.org
From: Philip Homburg <pch-ietf-driu@u-1.phicoh.com>
Sender: pch-bCE2691D2@u-1.phicoh.com
References: <50A2740C-98AE-4EA9-A290-B3231FFCBD0D@icann.org> <CAAedzxqkvPan_bGLQAPnViS6_59eNB2Hu4Ex+ZEYL89Qh7Mc_A@mail.gmail.com> <DBA89508-3E33-45D7-AC01-EC12CC875AF7@icann.org> <dc8008b8-ed7e-b5db-0efb-a0879443f93e@o2.pl>
In-reply-to: Your message of "Tue, 15 May 2018 18:07:04 +0200 ." <dc8008b8-ed7e-b5db-0efb-a0879443f93e@o2.pl>
Date: Tue, 15 May 2018 19:33:26 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/driu/e0m0fcW5mFbgvzc04rEU1weihL4>
Subject: Re: [Driu] [Ext] How to describe various flavors of DNS resolvers
X-BeenThere: driu@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "DNS Resolver Identification and Use \(DRIU\)." <driu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/driu>, <mailto:driu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/driu/>
List-Post: <mailto:driu@ietf.org>
List-Help: <mailto:driu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/driu>, <mailto:driu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 May 2018 17:33:39 -0000

>IMHuO, preventing downgrade attacks will not work because there are likely going
>to be environments that will block DNS-over-TLS and common DOH servers (China
>comes to mind). Browsers will have to keep working for these people.

Does that mean that browsers are also going to downgrade https to http if
https is blocked?

When I made a mistake with a Strict-Transport-Security header, there was
really no way I could convince firefox to let me do http.

In any case, I would prefer my browser to complain about downgrade attacks
and possibly offer an option to allow it. Not just silently switch to an
insecure protocol.

Related to this issue: a lot of people configure resolvers like 8.8.8.8
manually. It would be nice if we can avoid input fields for TLS, HTTPS, 
port, sni, certificate, etc. Way better if that kind of stuff is auto
discovered.