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

Petr Špaček <petr.spacek@nic.cz> Wed, 11 July 2018 08:23 UTC

Return-Path: <petr.spacek@nic.cz>
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 3B21E130EDF; Wed, 11 Jul 2018 01:23:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.021
X-Spam-Level:
X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 6qimPhtgKsj3; Wed, 11 Jul 2018 01:23:30 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 387C5130ED6; Wed, 11 Jul 2018 01:23:29 -0700 (PDT)
Received: from [IPv6:2001:67c:1220:80c:dc58:aeeb:87f9:51f8] (unknown [IPv6:2001:67c:1220:80c:dc58:aeeb:87f9:51f8]) by mail.nic.cz (Postfix) with ESMTPSA id E462F600FF; Wed, 11 Jul 2018 10:23:24 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1531297405; bh=LHnuk7xCUvKAhdUEXuQO/0trUrxPE3WKUOHJmcTstec=; h=To:From:Date; b=oR02KeTY6sBXzaFYnJl1HshzUA6KpdfLjWPQrVfY4FtgzaIauvpnwTjpeUDhDy75Q 8fYbCD5CE/pRb8n92SCwnT68kAF3xWAoNHnz9SGqT0dwgNVQ4LBipeNxQOcNawhVDU DlBmpl+rAgS3Gy8WY67TX9ZMfWRd8POl2r/Y6fyo=
To: Ryan Sleevi <ryan-ietf@sleevi.com>, Mike Bishop <mbishop@evequefou.be>
Cc: DoH WG <doh@ietf.org>, Adam Roach <adam@nostrum.com>, "driu@ietf.org" <driu@ietf.org>, Philip Homburg <pch-dnsop-3@u-1.phicoh.com>, dnsop WG <dnsop@ietf.org>, Ted Lemon <mellon@fugue.com>, Patrick McManus <pmcmanus@mozilla.com>, Paul Wouters <paul@nohats.ca>, Joe Abley <jabley@hopcount.ca>, HTTP Working Group <ietf-http-wg@w3.org>
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> <CAErg=HGsL3pNneqovHiumZZ2Vh5mw7q7cbyEhSXGHDAt1diVSw@mail.gmail.com>
From: Petr Špaček <petr.spacek@nic.cz>
Openpgp: preference=signencrypt
Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= xsFNBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABzSJQZXRyIMWgcGHE jWVrIDxwZXRyLnNwYWNla0BuaWMuY3o+wsF9BBMBCAAnBQJYa4wfAhsDBQkDwmcABQsJCAcC BhUICQoLAgQWAgMBAh4BAheAAAoJEM6N1qGlCiHkjGoP/3fvimzczcaqPM8lgY9fKKcr2DhH 42HF+fXsj0SvPeEoYDuWwIcsTGna6sdmrhCD/mB6eCNivAOcZYDH7j3YDgdFX2xy1sRY0ylF uyfcOT1Qn1xNTglSaf00gUWDgLBQB/USphB9Of6U1ka4gLJpCWKoZ3cLQe09cUpq9HOZYs/g WSNx9UTr06fcO0rtgZpg+IZJN/R2ORhQBwk4n2Dtx5J+Xyoy7ht1Fwz07BWAGJ4P8oJOhsi1 LukDD8ul3+6IeoSbRvyGpP6boegaMwxPR10VgsrYU2t1cK58iRv/xJ3TClb0JBn5aI3Bmh1j mPROrC55tvxRoeRLmxXHzbPZpWdbRjEcf9SEiAGNTgo9C+eXbubeSETWgisfJhZ4ebhkHnfz e+e+hvbaTSoFyMbKeOlfoYCmaDRBgT53i72HIkvO+HrVcmulZytw/yyOHuwObEFVgn3AeORv rb8I1kiv5W4wnZxDslhCeRR+wMGiKhc9ewU/mg3Rqo6GN+8mT0DHnsHuq1lu3WYslfNYkBSo nFcctFD2KXVozrwpn3vWJ4Qt6qu5XS1lDCD5WshZXh7qoISWnnMqsMyBW/R7WyiABeIz4uOg SkRwT2wSUYr+JtBZIjREy2JQDVhjf18DL1Qa7OxSes8YwWSx1pQAzwbfFx0gzRDyIT/39le4 pX430yTQzsFNBFhri/0BEADFp4ZfxSoKTAad0IkFK9CVoZ6XKywYLFNPPhzw++gbvHL2EX7Q qhEsqbsWMYpH4jc/Kq55OYYU/lIcULuD0Y9oDR26XFQou0FeSNnzRGb607U8OFOPQ+ei92Mm 1YPQ33GPj8GqbQpkAp35sfjJ64TH/EQY38RN33jsHRkhwtWU/6yo+RZs7cFRuihuLl8FuoP0 A5u/x+lNNeIBk8f27LVYrF81NSDDDYjnObCah+QLzGAwGDtjWkBVawpoHWwq58OQSx5piwyO CnFJeFONRcTRgOz239rsEA5LeYfmOGcnNwG6CHoJ5ZdWJw5OV9BoA7UTHG95xVHV5QiEm6q6 igI6wKV2RtFS7Roe0Wt8H7gC41JeqaKTUsGkz6uJraF8mmKyS8E+mSh3djmqdJNHF1pJqKxA xPYA9Y0jPnYWeEH4fPeOR2YvBjztsye9nOv1AuKNu03duzocyU95DfP/lwNJr5SH918Vf1t7 WcJj9dg6J9Jc5LOwg13Qr31TuZijrMdqM7LJKC/0tOkSeXNoMlHJOIqbqm7N414I0HytbENf 7AiyDxNA5TzJKkB0eBPLm2FMQCHLfasJHgbCrQut6nYw3f3Gn3+PDzGEHI9sfQv/mYvO77oR SGw+3Hy1ToxIncIirAyRpa5KdPLklDpADvpfkXjuL6IfZZ0OIWKLSRa/DQARAQABwsFlBBgB CAAPBQJYa4v9AhsMBQkDwmcAAAoJEM6N1qGlCiHkn54P/AgyzrffYzRq6d7vHfFhd8HzHHrU BtOK+5182DME1JX9Aow5Dy9kbfxAfTc4tbCY5EnhoUICbmVAJ5wL5lrGxQPSnulIyF8OmJjc VlGI6zXYvP0VHZ/L8dPcf+RPqhMCPpaxe2+h5XpPxvOkDLlnCrsA4J1bAGW5kpxdGnY4aRrv aKhtGMqgSwSx25l3RnoOROU/hTDV4EHCuTkMRfILmsuNT7It40iL5nyDiJ8o3p1CLjRwUzVn 4r4jE8DXhbWXaKJ0KQZpKiQDVV7qJcJIeBJvZpFfxJ44LxBct9TkC69ROntYhd6M7031DT3P IYW9VyMhLN5dRfzhEdFUc+3AlnoOOKcGwYiCnH2DwDva3ZicOAH8099mWZcwVL/sjKKbJGPo JbdT9C3gSnsoa3uBbsiChRhAno80Jsk/igb4QaMw4PsS3230kfBGkQ/oAPPM0iJ9kn8NXB/9 iBe5cKEUiiYQfSn9x1HyG0sT3/jSYaq3obmBNHJE24w/RKWoPsaKjoyaInAuU5L0cNZ30OWd eWFREIxlajFl2vXb9nCc80/i6PceJySiyJgd5cYEL4hfn/B6RXph9kAJySsqlIZoBhcwneGX mAS0M41jJjuIQdt5pkLhM9XoXjBFMGGtA/CtiicEgitItJfVCxdLG4bZOCrfPmevMGLxpEmB GouQ9dVQ
Organization: CZ.NIC
Message-ID: <32a1c574-d23f-d38e-546e-baa359e7e108@nic.cz>
Date: Wed, 11 Jul 2018 10:23:24 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <CAErg=HGsL3pNneqovHiumZZ2Vh5mw7q7cbyEhSXGHDAt1diVSw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/driu/r5ZcqzcRzcpB8BgtHJYXxsWupSc>
X-Mailman-Approved-At: Wed, 11 Jul 2018 05:20:24 -0700
Subject: Re: [Driu] [Doh] [DNSOP] 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: Wed, 11 Jul 2018 08:23:34 -0000

On 10.7.2018 20:57, Ryan Sleevi wrote:
> 
> 
> On Tue, Jul 10, 2018 at 2:09 PM, Mike Bishop <mbishop@evequefou.be
> <mailto: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.

Signatures in DNSSEC (i.e. RRSIG records) have validity period with
1-second granularity so in theory it allows fine-tunning. Of course
shorter validity means more cryptographic operations to update
signatures etc.

Taking into account that Cloudflare signs all recorsd on the fly, it is
clearly feasible for CDN to generate fresh signatures on every DNS request.

Petr Špaček  @  CZ.NIC


>     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).