Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-httpssvc-02

Alessandro Ghedini <alessandro@ghedini.me> Wed, 10 June 2020 22:45 UTC

Return-Path: <alessandro@ghedini.me>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356C43A1581 for <dnsop@ietfa.amsl.com>; Wed, 10 Jun 2020 15:45:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ghedini.me
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 7V6eCqzdOGhT for <dnsop@ietfa.amsl.com>; Wed, 10 Jun 2020 15:45:01 -0700 (PDT)
Received: from blastoise.ghedini.me (blastoise.ghedini.me [IPv6:2001:19f0:6c01:a56:5400:1ff:fe4a:5694]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 475553A157F for <dnsop@ietf.org>; Wed, 10 Jun 2020 15:45:01 -0700 (PDT)
Received: from localhost (unknown [IPv6:2a02:8010:6241:1:344f:b565:7289:633a]) by blastoise.ghedini.me (Postfix) with ESMTPSA id 9D80BDF212; Wed, 10 Jun 2020 22:44:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ghedini.me; s=mail; t=1591829098; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6konnoAFP2nnehYhreVRE5SfQtyvyDEs/hC7aCX5asU=; b=LsJMw1PuAOAxkXVoulwjwGyExeZMuZ94RSBCC6DoEeaDRJQYM0BzSeM3gH36UDKfaGX9yl ppr8aYI38nNOCqji9xeoao4pfDNRENHP4ZLPhqgEGavMMMxfHm05uD1P/AoO3oXz3UxUC3 HlGNtf61sQzT5W8f265PAsYsPLmOQsM=
Date: Wed, 10 Jun 2020 23:44:55 +0100
From: Alessandro Ghedini <alessandro@ghedini.me>
To: Ben Schwartz <bemasc@google.com>
Cc: Eric Orth <ericorth=40google.com@dmarc.ietf.org>, dnsop <dnsop@ietf.org>
Message-ID: <20200610224455.GA44302@sokka.flat11.house>
References: <20200417101932.GA2035@wakko.flat11.house> <CAMOjQcF10Ceh=O1-s58Kw_j_hekbCnfmQ9sMZGZiwvhDdbg2bA@mail.gmail.com> <CAHbrMsBCeg+3wDcbAJk=KZC1y0RPtLjznst2NVSDJQVSRL84XA@mail.gmail.com> <CAMOjQcHTgsJo4-9O=uZF9PTOGHz0s7BFmOBuCn4nStQ+6YnW1Q@mail.gmail.com> <CAHbrMsDTBDuuO27mS9KbeHC042incgPbtozHZZ7tx=X2o6=RiA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAHbrMsDTBDuuO27mS9KbeHC042incgPbtozHZZ7tx=X2o6=RiA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/yUtuaJjXQaoIu9wky89n3AfxHTc>
Subject: Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-httpssvc-02
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jun 2020 22:45:04 -0000

On Mon, Apr 20, 2020 at 11:02:00PM -0400, Ben Schwartz wrote:
> On Mon, Apr 20, 2020 at 9:25 PM Eric Orth <ericorth=
> 40google.com@dmarc.ietf.org> wrote:
> 
> >>>> 8. Maybe I'm missing something, but the following sentence in Section
> >>>> 6....4 seems
> >>>> wrong:
> >>>>
> >>>>    When SvcDomainName is ".", server operators SHOULD NOT include these
> >>>> hints,
> >>>>    because they are unlikely to convey any performance benefit.
> >>>>
> >>>> My understanding is that ipv4hint and ipv6hint are the way to solve the
> >>>> ESNI
> >>>> multi-CDN problem, so let's say I have "www.example.net" that CNAMEs
> >>>> to both
> >>>> "cname.cdn-a.example" and "cname.cdn-b.example". A client queries both
> >>>> A and
> >>>> HTTPSVC concurrently for "www.example.net", and receives two answers
> >>>> (the answer
> >>>> to the A query points to CDN A, while the answer to HTTPSSVC points to
> >>>> CDN B):
> >>>>
> >>>>     www.xample.net      3600 IN CNAME cname.cdn-a.example
> >>>>     cname.cdn-a.example 3600 IN A 192.0.2.1
> >>>>
> >>>> and
> >>>>
> >>>>     www.xample.net      3600 IN CNAME cname.cdn-b.example
> >>>>     cname.cdn-b.example 3600 IN HTTPSSVC 1 . alpn=h3 esniconfig="..."
> >>>>
> >>>> My understanding is that in this case the client could end up
> >>>> connecting to
> >>>> 192.0.2.1 (CDN A) with CDN B's ESNI config (or e.g. with the wrong
> >>>> ALPN). So if
> >>>> the server doesn't provide IP hints there would indeed be impact on
> >>>> performance
> >>>> because the client would just straight up fail to connect initially
> >>>> (e.g. maybe
> >>>> CDN A doesn't support HTTP/3, but CDN B's HTTPSSVC says the client can
> >>>> use it,
> >>>> or just because of the wrong ESNI config).
> >>>>
> >>>> Long story short, I don't think the text should discourage setting
> >>>> ipv4hint and
> >>>> ipv6hint here. I get that it's SHOULD NOT and not MUST NOT, but it's
> >>>> pretty
> >>>> confusing nevertheless.
> >>>>
> >>>
> >>> I don't think the hints are intended for this problem.  I think the
> >>> general design idea is that A/AAAA are the definitive address results for a
> >>> given name, and clients can just optionally shortcut querying A/AAAA if
> >>> given hints.
> >>>
> >>> In your example, I believe the "." HTTPSSVC entry indicates that the
> >>> A/AAAA addresses for "cname.cdn-b.example" should be used, so it doesn't
> >>> seem like there is a multi-CDN problem.  The correct addresses for the
> >>> correct CDN are used.
> >>>
> >>> But I think this might point out a potential problem with skipping hints
> >>> for "." results.  If the HTTPSSVC result passes through a CNAME, a
> >>> non-HTTPSSVC-supporting recurssive will handle the CNAME, but not lookup
> >>> A/AAAA for the HTTPSSVC.
> >>>
> >>
> >> I don't think this can happen.  Any CNAME that affects HTTPSSVC will also
> >> affect the corresponding A/AAAA queries, which are always issued
> >> simultaneously and to the same QNAME.
> >>
> >
> > alessandro@'s case was for multiple CNAME's and a recursive with behavior
> > that could follow those in different directions for the different
> > requests.  Not technically legal, but the more important question here is
> > whether or not significant instances behave in this non-standard way.  If
> > they do, this will lead to a situation where hints would be beneficial even
> > for "." records.
> >
> 
> Thanks for the explanation.  I would prefer to warn against this, rather
> than encourage more use of hints.  When SvcDomainName is ".", I think not
> including hints is going to perform better on average, even in the case of
> multiple CNAMEs, because the split-CNAME cases should be very rare (due to
> caching), but the hints add overhead to every response.  They can also
> impair load balancing if managed poorly.

I had to step away from HTTPSSVC for a bit due to other priorities (hence the
delay in responding), but I've been thinking about this some more and I see
another potential case where the A/AAAA and HTTPSSVC records might diverge.

Given the following records:

    www.example.net      3600 IN A 192.0.2.1
    www.example.net      3600 IN HTTPSSVC 1 . alpn=h3 echconfig="..."

* At time T, user A queries a resolver for the www.example.net A record, so the
  resolver fetches it from the auth server and caches it.

* At time T+5m, user B queries the same resolver for both A and HTTPSSVC
  records. The resolver serves the A record from cache, and fetches HTTPSSVC
  from the auth server (and caches it).

* The administrator of www.example.net now decides to move the zone to a
  different provider (either manually or with some automatic DNS load-balancer),
  with the following records:

    www.example.net      3600 IN A 192.0.4.1
    www.example.net      3600 IN HTTPSSVC 1 . alpn=h2

* At time T+1h+1s, user C queries the same resolver for both A and HTTPSSVC,
  the cache entry for A expired so the resolver fetches it again (this time
  pointing to the new provider), while HTTPSSVC is still served from cache.

So, unless I'm yet again missing something here, it seems to me that user C ends
up with the A record from the new provider, while HTTPSSVC comes from the old
provider. And since it has echconfig, the client is not allowed to fallback, so
it will be unable to connect to www.example.net until the HTTPSSVC cache
expires.

This seems like a more important failure scenario, as it would mean that moving
away from any provider that supports ECH will inevitably lead to downtime for at
least a portion of the zone's traffic until cache entries expire. So, what am I
missing here?

Also, speaking for my original CNAME scenario, I dug out the old discussion on
ESNI and multi-CDN setups https://github.com/tlswg/draft-ietf-tls-esni/issues/35
which seems to indicate that this is actually a fairly common setup. IIRC this
is what then prompted the addition of the "Address Set" extension in the ESNI
DNS record https://github.com/tlswg/draft-ietf-tls-esni/pull/136 which was then
replaced by HTTPSSVC, and at the time I had (mistakenly it seems) assumed that
the HTTPSSVC IP hints were intended to solve the same problem.

I'd be happy to provide text changes around this btw, though it's probably
better if we first agree on _what_ needs to be fixed, if anything.

Cheers