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: =?utf-8?B?UGV0ciDFoHBhxI1law==?= <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).