Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers

Ted Lemon <mellon@fugue.com> Tue, 30 June 2020 13:17 UTC

Return-Path: <mellon@fugue.com>
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 009973A0820 for <add@ietfa.amsl.com>; Tue, 30 Jun 2020 06:17:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 JG_K_fcYZ-68 for <add@ietfa.amsl.com>; Tue, 30 Jun 2020 06:17:43 -0700 (PDT)
Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3B783A082F for <add@ietf.org>; Tue, 30 Jun 2020 06:17:42 -0700 (PDT)
Received: by mail-qv1-xf31.google.com with SMTP id di5so4296058qvb.11 for <add@ietf.org>; Tue, 30 Jun 2020 06:17:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ieJM6/a5LVW2G09sAC5Y7ujXGSjORwRueatjsv55nWY=; b=f1FVKjkUZT1dTXDrLGwxWOdMUKKUq5Z0mUftS0lyTa6nGHdwJCGRF3h4PjLOr1EO/K ck1uFQsrOeFFaqJqdTtqttFN3J53djo9gN1D6XUNes0cHsXgcM5a9/0+Gky+ClSxJStv f7KkkpsnKE1FRBMf4qjJJydJ14qhjVfb05FSZNsfw0CzxL/EiO61ttdQuw2aV9d0LSaJ kjtS2P/X1qoV4QZEQTl6McjL2TUP1Rn/CMG2bH2DhDB3bLqKgpqpFZ2CYeF0xbKBIarG YIe2HbjSG45+zJObmfh5EMsiGC9izuHm92gg3iHsD+wqTIamOAslwMC7aGEvJq6Pm5lq ex0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ieJM6/a5LVW2G09sAC5Y7ujXGSjORwRueatjsv55nWY=; b=b7ZE5yhr4KMeN8jb1kcrvfyjRruREwtR5xbl22/MsBvPOJqBLSF2C/VKbjRI/55rs5 XAD41cW8xaWFUbOOQj3O3uSx0BfWdcoqQxj/YVytN3pfScL807OcF6c7a5ilgWMBuDIb skUggJcHjA18hAzQ8XpLYRxOOuNgv32b2sXSHA88C7/1y6XKwyzJXi+Og7fRsmH9g1oU +JxvJ2WGEJiumG37Qa0F3J31Lv1qHXgS632z5IjDeSB8YT7E3lIxHclxN4YH3OpAuyBn jeqoWkt0K2aaqayYfldnnvmu67f0FPa3wtaKhrl03TrbFGl8FMm/U7+QI4AhT9YfujK/ F5ZA==
X-Gm-Message-State: AOAM531cLg+dIByPLMIFeHf5+8pDBHNADSJBuPMgmab44aew+BX6PJs8 IkQkTfJ6nuwFLb0R6V0x3PhErScr3nI=
X-Google-Smtp-Source: ABdhPJyeTDF6CIg8hm/kVXnTAKRLzK1eUr2cLRdtQxejquXkGZv1N3kZVoFQDZeq4UHwyJFDXTENiA==
X-Received: by 2002:a0c:f681:: with SMTP id p1mr20081363qvn.2.1593523055539; Tue, 30 Jun 2020 06:17:35 -0700 (PDT)
Received: from ?IPv6:2601:18b:300:36ee:fc09:ab84:afa:8495? ([2601:18b:300:36ee:fc09:ab84:afa:8495]) by smtp.gmail.com with ESMTPSA id f4sm2909813qtv.59.2020.06.30.06.17.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jun 2020 06:17:34 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <6EC5A247-F873-4B0C-9773-E708D3B6AC77@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0C7E175F-BC18-40C9-AAF9-476DA97336D0"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Tue, 30 Jun 2020 09:17:32 -0400
In-Reply-To: <3421779.8U4dVgcHlH@linux-9daj>
Cc: add@ietf.org
To: Paul Vixie <paul@redbarn.org>
References: <CABcZeBPTkWeB40wpTowKvEJ-gXA3AL2e-BE+C_FC7Js7-D0DZQ@mail.gmail.com> <bd78f54e-038d-9cff-b6a8-c9c6323ed5f5@redbarn.org> <668384b7-90f5-4ff1-b9e2-d0257aee731d@www.fastmail.com> <3421779.8U4dVgcHlH@linux-9daj>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/AlZOnOCSYJyqQngIQUs4W5Ri9yw>
Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers
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: Tue, 30 Jun 2020 13:17:45 -0000

On Jun 30, 2020, at 5:19 AM, Paul Vixie <paul@redbarn.org> wrote:
> moving on, what i'd love to have is SDNCP rather than DHCP. S=secure, 
> N=network. because i want to know i'm getting what the operator of the network 
> wants me to get, and because there are other parameters besides RDNS that i 
> care about, such as whether there's a mandatory HTTPS or HTTP/3 proxy i will 
> have to talk to. because, IoT. if DHCP isn't useful because it's not secure, 
> we should stop using it. but before we could do that, we'd have to meet its 
> functionality in another way.

We tried that. Unfortunately, what we found is that it just moves the problem. Suppose you send out an SDNCP discovery request and get back one or more signed responses. Which one do you choose?

The answer is presumably that you choose the one you trust, but maybe you don’t trust any of them.  If you don’t trust any of them, is it because you are on a foreign network, or because the legitimate one(s) are being blocked?  If you do trust one, why do you trust it?  How do you establish trust in something you haven’t communicated with before? If you are able to set up a trust relationship, why not just use that to authenticate 802.1x?

Consider it from the other angle: suppose you just take what the network gives you, but you want to know if it’s legitimate or spoofed. How do you do _that_?

Well, it turns out we know how. You validate with DNSSEC; if that doesn’t work, you know your DNS server is lying to you. You validate with PKI. If that doesn’t work, you know that your TLS server is lying to you. 

If you want to trust the network, use 802.1x. Use the fact that 802.1x securely validated as an indication that you are on a trusted network, and can trust what the infrastructure says to you at least enough to bootstrap. If not, don’t trust anything the network tells you—validate it, or don’t use it. And by the way, even if 802.1x validates, that’s not at all a reason not to use DNSSEC and TLS and PKI. Use them too. So all 802.1x really buys you is that it’s harder for an on-link attacker to trick you into wasting time validating stuff that won’t validate, which is probably why it’s not more widely used.

So the question is, what problem are you solving with SDNCP that isn’t already solved with DNSSEC, TLS and PKI?

The only answer we came up with is that it might be nice to be able to know that we are speaking to the same operator we were last time. But we didn’t actually identify a compelling use case for that, and consequently the work was abandoned.