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

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

Received on Wednesday, 11 July 2018 20:43:03 UTC