Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Ted Lemon <mellon@fugue.com> Tue, 21 August 2018 02:31 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14471130E02 for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 19:31:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 pfzgosoS5Ito for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 19:31:44 -0700 (PDT)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 3BC76130DF6 for <dnsop@ietf.org>; Mon, 20 Aug 2018 19:31:44 -0700 (PDT)
Received: by mail-it0-x234.google.com with SMTP id d9-v6so2232958itf.2 for <dnsop@ietf.org>; Mon, 20 Aug 2018 19:31:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T+3w2dgWEuXxCd4FmUbw4XHnVMOHosyzCUwNousZmzg=; b=BqUDe7OFTdvm+G1bLg7V1T0uakTmVA/u/SWLp1upkLZOppxCbQMQ2dCWhXKdpoaSfc j3D5OZrxWi5EzfTEIsW9WcOHfRA7jXecvXhnEKGbJ9kE3YpYLkLUUSEhSFiTC9sp/0Pn 02WYWTVy3kDUMdUIWmvDcJI5EnRqU8e4yxFKU4H111Bj/PR2D5R0bKKq94cN9Kjyflzf H/24eYjORtJtVxGt2TLaLfwqhv4q1LQTL71quQOtExi/F4exuAkYEl4+IkLKOLy/X9Lr X4xrp2TPK8FvLMIND7SP2fkiDQcQ5Exi2TVPkJtyRdQCLUxFL+KzXCz7Ryk5E2VSzIaF 8G6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T+3w2dgWEuXxCd4FmUbw4XHnVMOHosyzCUwNousZmzg=; b=p2uNr52FXi7RwKTZgImLSxClypC89Z2UwLWb8yggg1YUhyXbUuUd5xEsD71epnJ7ew u31SUtozg/M+kq0FMroJ5etexu2truPAfp3wKEWYL3katQHeeD6XInoV0zlIYD8NONZm wXRU1Qq3V90X12F5fd4zMa5UC+yqCP5kzSikr5jyY7Ho0gxTaZ23pvO3K6TDxGA4nno0 Fpl2GSBcXCp8Fle5n0l3imMITIQ1jZqUxZD712S1DPxQ1xuMTpv2Bogally4lgE11m5l 82WfKLctvemKVKu86J51vXnyLWKJkdzlPAFNJyjYBuwYNqzlJTPol2Zhp9O0YDqwMwwU TzQg==
X-Gm-Message-State: AOUpUlFCJKoV4bnPN7rrQU0tBtmKBnHFFU1b47uKWBGysD5wUiu95IBp hHxiWPJF6hForR9QWckM0WaaGFlGk8IWL214B5d/ninj
X-Google-Smtp-Source: AA+uWPwBSFZUdCrJe6gao29j0LSSH4igoNC3xvWllhRqEnEzXZhQjGQJ8kqPm1QOLh7zXiqVGu89B2m4hkkdDDjSJFo=
X-Received: by 2002:a02:88ad:: with SMTP id n42-v6mr2686395jaj.38.1534818703500; Mon, 20 Aug 2018 19:31:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Mon, 20 Aug 2018 19:31:02 -0700 (PDT)
In-Reply-To: <20180821022627.50A64AD6A31@fafnir.remote.dragon.net>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <alpine.DEB.2.20.1808201720060.3596@grey.csi.cam.ac.uk> <23C2BA0B-B4A7-49F2-9FFD-90B90E2928B5@bangj.com> <56B7EA81-A840-4320-BDD0-781E9D999904@vpnc.org> <B5CCB149-BEE2-46D4-BF3C-C32D5BCA3EA3@bangj.com> <20180821014030.C2678AD6354@fafnir.remote.dragon.net> <922DCF48-BA8A-42B8-99BA-2B367D981568@bangj.com> <20180821022627.50A64AD6A31@fafnir.remote.dragon.net>
From: Ted Lemon <mellon@fugue.com>
Date: Mon, 20 Aug 2018 22:31:02 -0400
Message-ID: <CAPt1N1np9KdMmqE09AhsvH-macAer2dMxsUUpF4AYVSeB0g-oA@mail.gmail.com>
To: Paul Ebersman <list-dnsop@dragon.net>
Cc: Tom Pusateri <pusateri@bangj.com>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009df6720573e8d3b1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/WgdO35uWIWZPWCBYX6w3b6P-dLU>
Subject: Re: [DNSOP] Draft for dynamic discovery of secure resolvers
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Aug 2018 02:31:47 -0000

This is why we need to actually think about trust and not just handwave.
 There are a number of serious misconceptions in what you've said, Paul.

DHCP _is_ worse than TOFU, because there is an opportunity for attack at
every lease renewal, not just the first time you ever talk to a particular
DHCP server.   I actually proposed a protocol that would have worked nicely
for TOFU, but it didn't get consensus, so we don't even have TOFU-level
authenticity.

The rest of what you said is nice, but "we have to balance theoretical risk
versus sane and widespread deployment" is a statement that sounds a lot
better if we *do the math.*   If we just decide to do something without
doing the math, then we aren't really balancing anything.   We're just
deciding not to do our homework, because math is hard.

On Mon, Aug 20, 2018 at 10:26 PM, Paul Ebersman <list-dnsop@dragon.net>
wrote:

> ebersman> That may be the consensus at the IETF but it's not even close
> ebersman> the consensus with ISPs, nor large enterprise. That seems to
> ebersman> cover most of the eyeball/consumer... DHCP is still how much
> ebersman> of the world gets connected and that hasn't changed in decades.
>
> pusateri> You're misquoting me and arguing against a point I didn't
> pusateri> make. There was no one saying we don't need DHCP. There was a
> pusateri> general agreement that DHCP should not be extended.
>
> pusateri> The DHC working group never completed the work for DHCP
> pusateri> authentication. It's not trustworthy enough in its current
> pusateri> form to add more things to it.
>
> And I'd argue that this is also an IETF opinion, not the majority of the
> internet. There's a reason it's still the most widespread configuration
> management for devices. "Not trustworthy enough to extend" is a fine
> academic opinion but doesn't hold water in the marketplace.
>
> DHCP is no worse currently than TOFU. We trust that the OFFER packet
> will be from the DHCP server we're supposed to use. Trust On First
> Use. Not great but it works more than not. At least that's the argument
> I kept hearing for TOFU. We actually have operational experience of
> decades for DHCP and this isn't a wide spread enough problem to kill any
> innovation forever because it's not perfect.
>
> If we want the world to use what the IETF develops, we have to be able
> to balance theoretical risk vs sane and widespread deployment.
>
> If not, someone will just wind up shoving this into yet another DHCP
> vendor option and every vendor will be different. That will be even less
> secure.
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>