Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

Ryan Sleevi <ryan-ietf@sleevi.com> Tue, 10 July 2018 18:57 UTC

Return-Path: <ryan-ietf@sleevi.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 40CF5131052; Tue, 10 Jul 2018 11:57:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 TCO7Gzya_x2R; Tue, 10 Jul 2018 11:57:26 -0700 (PDT)
Received: from homiemail-a129.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E81130E51; Tue, 10 Jul 2018 11:57:25 -0700 (PDT)
Received: from homiemail-a129.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a129.g.dreamhost.com (Postfix) with ESMTP id 614F010002181; Tue, 10 Jul 2018 11:57:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=NMzpBgH2U2T5q54GvtwFqGAauEY=; b= NCDWlsEVSi7jzISpcBch+daRshwVdcBtuZOsU++CA0HC+NWXHyE9H4eeTFDWQc8b RJUH/8kfUThiuv0AAjux+4dW/xO6iT3Qxh9kTeu/5yRuyzlqwBYOGlxlScF/HHF2 OPAkH9XogBlo9Ng7NxlTu08hA0qsE+LloC5RC2+gG2U=
Received: from mail-it0-f47.google.com (mail-it0-f47.google.com [209.85.214.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a129.g.dreamhost.com (Postfix) with ESMTPSA id 51CC410002180; Tue, 10 Jul 2018 11:57:25 -0700 (PDT)
Received: by mail-it0-f47.google.com with SMTP id p185-v6so127200itp.4; Tue, 10 Jul 2018 11:57:25 -0700 (PDT)
X-Gm-Message-State: APt69E2WF8f3cRuhS51sAn9dKNDGpwwp0AoSFPenPbtoX8052mJ/yNac AhDHFHOxxYgLz+Mob9ApmXHCSX1yk9IG5GBIMi8=
X-Google-Smtp-Source: AAOMgpf29o/XI/QmgdbET3+qmN80+ur+RYo1h4RZGDrLvB4XnOred8MZcckL5u3Ia8MiCAPhh5JZv36/tMWwwHNTXQ0=
X-Received: by 2002:a24:684d:: with SMTP id v74-v6mr20894074itb.88.1531249044728; Tue, 10 Jul 2018 11:57:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a02:244:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 11:57:24 -0700 (PDT)
In-Reply-To: <BYAPR08MB3944C30A1016F6978EA325F8DA5B0@BYAPR08MB3944.namprd08.prod.outlook.com>
References: <m1fcoe5-0000GuC@stereo.hq.phicoh.net> <alpine.LRH.2.21.1807101056140.5219@bofh.nohats.ca> <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <e1675184-f0bc-670d-3db1-b99a9daf1657@nostrum.com> <CAJhMdTOZtOpF_aK-ZzP0DfkDMcAtTKFLdSpKkrSPvP1cOgnOjQ@mail.gmail.com> <CAPt1N1=Xky1MjmbzdnR2zxcVbD3mz0O3Qo_uEVK96uMLUrwu8g@mail.gmail.com> <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com> <CAErg=HGMkYFBMG2gHykXpPc5ry=DVsZHohSen-tT7-_281q7VQ@mail.gmail.com> <BYAPR08MB3944C30A1016F6978EA325F8DA5B0@BYAPR08MB3944.namprd08.prod.outlook.com>
From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Tue, 10 Jul 2018 14:57:24 -0400
X-Gmail-Original-Message-ID: <CAErg=HGsL3pNneqovHiumZZ2Vh5mw7q7cbyEhSXGHDAt1diVSw@mail.gmail.com>
Message-ID: <CAErg=HGsL3pNneqovHiumZZ2Vh5mw7q7cbyEhSXGHDAt1diVSw@mail.gmail.com>
To: Mike Bishop <mbishop@evequefou.be>
Cc: Ryan Sleevi <ryan-ietf@sleevi.com>, Adam Roach <adam@nostrum.com>, Ted Lemon <mellon@fugue.com>, Joe Abley <jabley@hopcount.ca>, DoH WG <doh@ietf.org>, "driu@ietf.org" <driu@ietf.org>, dnsop WG <dnsop@ietf.org>, Paul Wouters <paul@nohats.ca>, Patrick McManus <pmcmanus@mozilla.com>, Philip Homburg <pch-dnsop-3@u-1.phicoh.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000005fba590570a9b393"
Archived-At: <https://mailarchive.ietf.org/arch/msg/driu/gpZiEHX4wvrxMdgEAYpNPFNlyDU>
X-Mailman-Approved-At: Tue, 10 Jul 2018 15:38:58 -0700
Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal
X-BeenThere: driu@ietf.org
X-Mailman-Version: 2.1.27
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, 10 Jul 2018 18:57:29 -0000

On Tue, Jul 10, 2018 at 2:09 PM, Mike Bishop <mbishop@evequefou.be> wrote:

> Yes, the multi-CDN case is the scariest aspect of coalescing and the
> various DNS tricks we’ve been doing in recent years.  The server may not be
> malicious, may not even be misconfigured – site X uses DNS to dynamically
> share load between CDNs A and F.  If X decides to start moving more load to
> A, F could in all good faith continue to route clients to itself by
> providing cached, signed DNS records.
>

Yup. And, at least for browsers that follow a Priority of Constituency
model, it seems more important to ensure that site operators wishes are
respected over that of the CDNs they've used, or for their being a more
explicit signal from the user that it truly intends to ignore the site
operator.


>
>
> The industry norm is that changing the DNS record’s CNAME to a different
> CDN is the cut-over, regardless of whether the other CDN remains
> configured.  It’s effectively acting as a “hot standby.”  If it had to
> provided better proof of freshness, that might be sufficient, but how fresh
> is sufficiently fresh?  And does DNSSEC provide that freshness guarantee?
>

Right, these are questions that need to be answered, and not just with
abstract theoretical mitigations that don't or can't be deployed.


> However, F could do this today with Alt-Svc and have the same impact.
> Secondary Certificates provides another way this might happen.  So this
> ship might have already sailed.
>

The ship has only sailed for those foolish enough to ship those features :)
That is, these are real security concerns, they have not been
satisfactorily addressed, and security conscious implementations have held
off implementing these features for precisely this reason. If there are
implementations that have shipped, without understanding or considering the
security harm they're doing, that doesn't seem like a good argument to keep
building more features on the buggy premise.

If they believe they have sufficiently mitigated those very real and
practical security concerns, they would hopefully be sharing those concrete
strategies and tradeoffs, rather than a Security Considerations that
acknowledges the dragons without adequately describing how to avoid them
(or how not to).