Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal
Mike Bishop <mbishop@evequefou.be> Wed, 11 July 2018 20:42 UTC
Return-Path: <mbishop@evequefou.be>
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 705BB1277BB; Wed, 11 Jul 2018 13:42:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.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 mEhFFremXvW0; Wed, 11 Jul 2018 13:42:39 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::703]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D86F130E18; Wed, 11 Jul 2018 13:42:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AuPPMbGuiP2BK/A6GT1Ed5mpiV1rsFP8iQ5Qmq38fkU=; b=JHgeRrcyDDymIlqoTGuyjTZ9x2Ts2meHeixxxbdy9itn1vUM6clkTt+zmxjpyLH8TsVK0aWf/ppsY5/cRYI/JTIxs2mG0e8PawAVz0heXGL7lZZAj31Rk4AFGtVuWSc/GQrplc06hLNryLTvRV8odFVDvhSNPC2gizsYtyR0nmU=
Received: from BYAPR08MB3944.namprd08.prod.outlook.com (52.135.194.30) by BYAPR08MB4887.namprd08.prod.outlook.com (20.176.255.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.20; Wed, 11 Jul 2018 20:42:34 +0000
Received: from BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::2080:90d4:850e:af3]) by BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::2080:90d4:850e:af3%2]) with mapi id 15.20.0952.017; Wed, 11 Jul 2018 20:42:34 +0000
From: Mike Bishop <mbishop@evequefou.be>
To: Petr Špaček <petr.spacek@nic.cz>, Ryan Sleevi <ryan-ietf@sleevi.com>
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>
Thread-Topic: [Doh] [Driu] [DNSOP] Resolverless DNS Side Meeting in Montreal
Thread-Index: AQHUGPBzCI/u0plagkGhGyhgf/ZcS6SKfHmA
Date: Wed, 11 Jul 2018 20:42:34 +0000
Message-ID: <BYAPR08MB39446FC958EE6231EE201045DA5A0@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> <CAErg=HGsL3pNneqovHiumZZ2Vh5mw7q7cbyEhSXGHDAt1diVSw@mail.gmail.com> <32a1c574-d23f-d38e-546e-baa359e7e108@nic.cz>
In-Reply-To: <32a1c574-d23f-d38e-546e-baa359e7e108@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be;
x-originating-ip: [38.134.241.6]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR08MB4887; 7:gzqzOItI00S+HqG48e1K+TOt7VFKLj70VIBcJjZZFNPwVCYeehc1dYkd0qSOW1+Nd+v6e4xn1J/rbjXn79RyO9ktGjzjUJz7JqU2ByxtQEMSccwMoSeX/wcOCXDupr/tQ6D8+hzlDDuc6RuA5dCrIXwL6wjYmLf2QD/B0mVBf5hQ+WkBcnunAVmCpILGedyNDmNIZ8UPc5B2s+5lm7Ekd098WFUggyo15c2fWj3Md0hVPCbvvdi3owBg4abeeBZq
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: a8502440-8072-41ac-753b-08d5e76ed4f3
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989117)(5600053)(711020)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990107)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:BYAPR08MB4887;
x-ms-traffictypediagnostic: BYAPR08MB4887:
x-microsoft-antispam-prvs: <BYAPR08MB48871D89CD2C04E3B58784FADA5A0@BYAPR08MB4887.namprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(209352067349851)(192374486261705);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231311)(944501410)(52105095)(3002001)(93006095)(93001095)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123564045)(2016111802025)(20161123560045)(6072148)(6043046)(201708071742011)(7699016); SRVR:BYAPR08MB4887; BCL:0; PCL:0; RULEID:; SRVR:BYAPR08MB4887;
x-forefront-prvs: 0730093765
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(39830400003)(376002)(346002)(396003)(199004)(189003)(13464003)(74482002)(105586002)(25786009)(81166006)(102836004)(6506007)(229853002)(53546011)(8676002)(81156014)(76176011)(7416002)(256004)(5660300001)(74316002)(68736007)(2900100001)(8936002)(99286004)(33656002)(7736002)(6436002)(97736004)(53936002)(305945005)(14454004)(9686003)(106356001)(7696005)(2906002)(55016002)(4326008)(110136005)(476003)(316002)(93886005)(54906003)(478600001)(14444005)(6116002)(86362001)(11346002)(3846002)(486006)(5250100002)(26005)(446003)(186003)(66066001)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR08MB4887; H:BYAPR08MB3944.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-microsoft-antispam-message-info: MqriETs1p1yQf89wt096RDlwyExowc2x9L4Vv0gQQ4yTCjBdwCPElbejjhHgdqHMnv327Pu6no3943DtLL3tFlsrb5krpu9smppMKUiiRAP0UnSAa9ekt1ma1OvKMznR0/lg2xQnfSLlUETIvdkFMrGleCUVeL9T3UyVldQT2Z1QJmKlQdin4+eH4G1QIbL1DXf2labXi1orLVAnnMzwtQjWhdh9bvlqgidqO1VSLPJKX7AE89e6BmWwnibJs69nxdqR9WnzUe5dFQ6+xuCeuNmlGrnFGv6m8lqEd6RLfzT5/KfVC//sruYu7vyurPXEbPJfzu9PsYnaog6qHFUpAygqFin+pSEZou3/UuVVB/M=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: a8502440-8072-41ac-753b-08d5e76ed4f3
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2018 20:42:34.5785 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB4887
Archived-At: <https://mailarchive.ietf.org/arch/msg/driu/TjPX2pJhj1GRH3Ai1vMD0AxD4I8>
X-Mailman-Approved-At: Wed, 11 Jul 2018 14:13:55 -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 20:42:43 -0000
But it's not necessarily the CDN that's generating the signed records in the general case. You're wanting proof that the customer's domain is pointed to that CDN, so it's signed by whoever manages the DNS infrastructure instead. That could be one of the CDNs, or the customer's operations team, or a third-party provider altogether. But yes, clearly it's possible for at least some parties to do online signing in real-time. That's at variance with the airgapped signature key design I've heard in other cases. -----Original Message----- From: Petr Špaček [mailto:petr.spacek@nic.cz] Sent: Wednesday, July 11, 2018 1:23 AM 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; 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> Subject: Re: [Doh] [Driu] [DNSOP] Resolverless DNS Side Meeting in Montreal 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).
- Re: [Driu] [DNSOP] Resolverless DNS Side Meeting … Patrick McManus
- Re: [Driu] [Doh] Resolverless DNS Side Meeting in… manu tman
- Re: [Driu] [DNSOP] Resolverless DNS Side Meeting … Philip Homburg
- Re: [Driu] [DNSOP] Resolverless DNS Side Meeting … Paul Vixie
- Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Me… Tim Wicinski
- Re: [Driu] [Doh] Resolverless DNS Side Meeting in… Patrick McManus
- Re: [Driu] [DNSOP] Resolverless DNS Side Meeting … Paul Wouters
- Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Me… Adam Roach
- Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Me… Paul Wouters
- Re: [Driu] Resolverless DNS Side Meeting in Montr… Patrick McManus
- Re: [Driu] Resolverless DNS Side Meeting in Montr… Ted Lemon
- [Driu] Resolverless DNS Side Meeting in Montreal Patrick McManus
- Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Me… Joe Abley
- Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Me… Adam Roach
- Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Me… Joe Abley
- Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Me… Ted Lemon
- Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Me… Joe Abley
- Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Me… Adam Roach
- Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Me… Adam Roach
- Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Me… Ted Lemon
- Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Me… Patrick McManus
- Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Me… Philip Homburg
- Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Me… Adam Roach
- Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Me… Dave Lawrence
- Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Me… Joe Abley
- Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Me… Adam Roach
- Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Me… Paul Wouters
- Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Me… Dave Lawrence
- Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Me… Ryan Sleevi
- Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Me… Dave Lawrence
- Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Me… Daniel Kahn Gillmor
- Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Me… Tony Finch
- Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Me… Mike Bishop
- Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Me… Ryan Sleevi
- [Driu] SRV and HTTP Mark Nottingham
- Re: [Driu] [DNSOP] SRV and HTTP Ólafur Guðmundsson
- Re: [Driu] [DNSOP] SRV and HTTP Mark Andrews
- Re: [Driu] [DNSOP] SRV and HTTP Mark Nottingham
- Re: [Driu] [DNSOP] SRV and HTTP Mark Andrews
- Re: [Driu] [DNSOP] SRV and HTTP Dave Lawrence
- Re: [Driu] [DNSOP] SRV and HTTP Dave Lawrence
- Re: [Driu] [DNSOP] SRV and HTTP Mark Andrews
- Re: [Driu] SRV and HTTP - 18:30 Tuesday Mark Nottingham
- Re: [Driu] [DNSOP] SRV and HTTP Patrik Fältström
- Re: [Driu] [DNSOP] SRV and HTTP Mark Andrews
- Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Me… Petr Špaček
- Re: [Driu] SRV and HTTP Leif Hedstrom
- Re: [Driu] [DNSOP] SRV and HTTP Patrik Fältström
- Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Me… Mike Bishop
- Re: [Driu] [DNSOP] SRV and HTTP Nico Williams
- Re: [Driu] [Doh] [DNSOP] SRV and HTTP Joseph Lorenzo Hall
- Re: [Driu] [DNSOP] SRV and HTTP Mark Andrews
- Re: [Driu] [DNSOP] SRV and HTTP Nico Williams
- Re: [Driu] [DNSOP] SRV and HTTP Mark Andrews
- Re: [Driu] SRV and HTTP - 18:30 Tuesday (room cha… Mark Nottingham
- Re: [Driu] [Doh] SRV and HTTP - 18:30 Tuesday (ro… Shane Kerr
- Re: [Driu] [Doh] SRV and HTTP - 18:30 Tuesday (ro… Jim Reid
- Re: [Driu] [Doh] SRV and HTTP - 18:30 Tuesday (ro… Tim Wicinski
- Re: [Driu] [Doh] SRV and HTTP - 18:30 Tuesday (ro… Ray Bellis
- Re: [Driu] Resolverless DNS Side Meeting in Montr… Patrick McManus
- Re: [Driu] [Doh] SRV and HTTP - 18:30 Tuesday (ro… Sebastiaan Deckers
- Re: [Driu] [Doh] SRV and HTTP - 18:30 Tuesday (ro… Adam Roach
- Re: [Driu] [Doh] SRV and HTTP - 18:30 Tuesday (ro… Adam Roach