Re: [DNSOP] draft-ietf-dnsop-svcb-httpssvc-01 feedback

Brian Dickson <brian.peter.dickson@gmail.com> Fri, 06 December 2019 23:14 UTC

Return-Path: <brian.peter.dickson@gmail.com>
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 A7E281209B9 for <dnsop@ietfa.amsl.com>; Fri, 6 Dec 2019 15:14:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 vfX9xhdPMRhv for <dnsop@ietfa.amsl.com>; Fri, 6 Dec 2019 15:14:07 -0800 (PST)
Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 66F3D1209AC for <dnsop@ietf.org>; Fri, 6 Dec 2019 15:14:07 -0800 (PST)
Received: by mail-ua1-x934.google.com with SMTP id x15so3550054uar.3 for <dnsop@ietf.org>; Fri, 06 Dec 2019 15:14:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RXjUX7pLAStBBqCSXksgVx1Ai8C2MULQhiV2W3H4bNs=; b=oRax0O4EBlAphUFWs41GnGCcy9tFhiBrLibUHiJOvej2kEWT2kw8AuY3HbYss2A77m EV97NyjBgOCjqIwnf01ls8zu5jlXWADOxKDgkAGINZhCqK4VHORsPAT3mRn73M486yTt 8JwtrAe+XnZhUOdSC3fiUvFmvzhgsNh1eBHzzDccImKlQk+slDQlVpzvvEJy2qNJZRU/ 6I0lzEaIptZICmjcfyum4E0e4h3KBEetIQ2B6E9pOtHMU/AOwPdnXelW3DwnXsBTD2P4 gzFetpeVp5HypVIZ9HaXUhR0Hp26z0cb70KNyQf+2iKRlWcw5h2nnF4JczB/gO83CaVo 49TA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RXjUX7pLAStBBqCSXksgVx1Ai8C2MULQhiV2W3H4bNs=; b=h72bwGOBnVH8AgkFAxEob+od1DzwS0tTkSGrBySx4oABln7kIvANur71jGzL8sd0M6 EWWp4UW3EViwBPNCGDXok941V2tLNMmEQgkS49wvggsdjN/GtlQGscCQ3W4V3Zv2qdj7 yhPZnwF/V7AkikP75BqyDqxDJoqGPbPNOfdG5TzcpH7RtqTyH4EUUuQgWK5Lfx3y/qxf xpen+3ystTGvott/1S5pDXQy8IHFPtjjDBc2L1w5H3MCJFVIgRisDjCeBzZKZIqfpp9N 6Bmqeu8Kjti+o/zqgNjNpi86cv91rZeaqKuScx8D/19Q7ohJpOyNoXw9HpUuO8v9FG6o 6BFg==
X-Gm-Message-State: APjAAAWtQUgn+4E6YgH6k6IiOefPI23Ozfkv4oJXzltroBTP2BEOoI2r 3OVkus0C+1VJLZOegVXTI/CsMFYiLZcuHsxb2HE=
X-Google-Smtp-Source: APXvYqw5syITddTonxSBhxPEPGwMIdWTw7MVE7MnUYXUEyYtcSeQjVUALJsj1/Q+yta/ChaiEQsxagx6D+hCiZ5sPA4=
X-Received: by 2002:a9f:372c:: with SMTP id z41mr14743643uad.87.1575674046494; Fri, 06 Dec 2019 15:14:06 -0800 (PST)
MIME-Version: 1.0
References: <CAMOjQcGP3=+_fb9pt3dvF27kR1ENH+=2L28EDNPQU6JF8zkrzQ@mail.gmail.com>
In-Reply-To: <CAMOjQcGP3=+_fb9pt3dvF27kR1ENH+=2L28EDNPQU6JF8zkrzQ@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Fri, 6 Dec 2019 15:13:55 -0800
Message-ID: <CAH1iCirdFrT_v-FBqaC=WUfaY52DyeYLh5VWbeVsw2YwscDCpA@mail.gmail.com>
To: Eric Orth <ericorth=40google.com@dmarc.ietf.org>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d2bcc6059911337d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qXR52zG8PahjUHZEzcix7VDqzCI>
Subject: Re: [DNSOP] draft-ietf-dnsop-svcb-httpssvc-01 feedback
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: Fri, 06 Dec 2019 23:14:12 -0000

On Fri, Dec 6, 2019 at 2:45 PM Eric Orth <ericorth=
40google.com@dmarc.ietf.org>; wrote:

> Been reviewing the latest draft with a bunch of relevant experts within
> the Chrome team.  As has been stated in previous emails and in WG sessions,
> we generally like the HTTPSSVC approach and are very interested in trying
> out an implementation.
>
> Some specific feedback:
>
>    - Section 2.5: We see no valid reason to support an alias chain 8
>    nodes long.  Such a case is likely only configuration error, and following
>    the full chain would subject our users to bad performance that the
>    configurer is not likely to notice and fix.  Therefore, unless somebody
>    comes up with a good reason that longer chains need to be supported, we
>    intend to only follow 1 or 2 links before giving up on following the chain
>    further, and the spec should be updated to say that such chains should be
>    limited as such.  I hear not everybody in the stack can reasonably enforce
>    this limit, so maybe state that longer chains are not valid, should not be
>    created, and clients/resolvers that can enforce limits should use the value
>    specced here for that enforcement.
>
>
There are several important points on this, particularly from the
perspective of DNS folks.

   1. The main motivation for ANAME, and for us being happy with H6C
   solving the problems with ANAME and making it un-necessary, is that current
   "apex CNAME hacks" are all limited to incompatible vertically-integrated
   providers. Too short an alias chain has the potential effect of
   constraining actual use of H6C to vertically-integrated providers. This is
   not acceptable, and non-negotiable; the minimum length needs to be
   demonstrated as facilitating real-world use in heterogenous environments.
   2. The whole concept of CNAME (and implicitly H6C) is that the owner of
   the CNAME (left hand side) and the target (right hand side) aren't
   guaranteed to be under control of a single administrative entity. The
   operator of the target may not even be aware of being the target of a
   CNAME. So, the semantic construct "configurer" isn't really guaranteed to
   exist, and performance issues may not reside in a single entities' area of
   responsibility.
   3. Notwithstanding the desire of browsers to have good performance,
   there is no way to force good performance universally, regardless of such
   desire. DNS latency is often unrelated to number of iterations in
   CNAME/DNAME/H8C.
   4. Latency will only occur at the time of first resolution of any given
   chain. Resolver caches will serve the results for min({TTL of all records
   in the chain}). Refreshing expired records (similar to HAMMER) can mitigate
   any cache expiry impact.

There are any number of reasons longer chains might be created, and I think
having data to analyze on the distribution of lengths of chains, plus the
relative popularity, should inform any choice of limit.
Once that data is available, I'd suggest something like 3 sigmas above
median value, as a starting point for the discussion.

Brian