Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-httpssvc-02
Ben Schwartz <bemasc@google.com> Mon, 20 April 2020 23:39 UTC
Return-Path: <bemasc@google.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 EA3A33A130F for <dnsop@ietfa.amsl.com>; Mon, 20 Apr 2020 16:39:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.699
X-Spam-Level:
X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 rvI6C_Q8EHTX for <dnsop@ietfa.amsl.com>; Mon, 20 Apr 2020 16:39:21 -0700 (PDT)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 DDC553A130C for <dnsop@ietf.org>; Mon, 20 Apr 2020 16:39:20 -0700 (PDT)
Received: by mail-wm1-x334.google.com with SMTP id r26so1582789wmh.0 for <dnsop@ietf.org>; Mon, 20 Apr 2020 16:39:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IcBfeozNmxguAJLa1xlu6x2A8rDit3hPvdUHfZ12yxs=; b=YgiYBWlE6N+zvKYk1+OBBqOcscI9lEXDYUNVgQSiEdaRB4HdUCgmeDzvXf0V//ovdl jUIqi0ySKFNsdjwFXSs3xZaF/srZYMStoFV7xenxHa9GyVsGywwlBlWzHcYpyAFHfqou k7x5CVqzYglPVF+iKPMHz4q6ua819OqKhE7gJyxDaMJK5ZHSgTzcJVgFVVjPpJPqA2m8 2YE4hhiEHbyvX78vL8r0Fea9o8kvHyi2Lau/C9qwu01bsQ0D8ketJNjzAJ4llrVaaGOV H8fZnXr965crYY9TpSQHU9tvw17teSPF/W87qYUgdgiJfwDv3LwcSrIsdR4Ar24HXnWW x2nQ==
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=IcBfeozNmxguAJLa1xlu6x2A8rDit3hPvdUHfZ12yxs=; b=sxr5qRCVZgwrVjOSK/c6uDR/dqCSq/gByI50H3NXSGOSbNSfFcNTie/+L/4LMhwvu8 rVpcJH/e25Dnvoj51tKlSBHDTJsIi9X2mFz56XR8N81Xf2nCNEjkHGuqQ8BGPgF1+CJT BWYgxyCaaD7cY5gW/u8J2zDdGYZN3YWspJZiKNcaoJIH4g41SHqiBcXShKj5046n2P1W slQ2DRzMdzjntUsRf4hydqRRdWY4R3nljZsEng7f+BGxDJ4DP3vVZqSLkv1bZHh5ygdQ 9Rg/8o6lrJw3k63Fvic520O6uTKGkJ0GdgoW3sm6U26xntDj7GJ6KEC0zW667m0WwWg8 yzrQ==
X-Gm-Message-State: AGi0PuY1xLi64fWV6/n2/M2OV182pfhx3Wa62qgPVO2uevxPsY49nXGe APGEKS9O2LFLcLrU14zrz8QTJMCOObToK1d26EnAZdXP
X-Google-Smtp-Source: APiQypIrMSxPXMWQLYK3g971mbBABl2PQSz9BvhIkwBo/8kN1nrMMjXXwzlt5nxiZCQ5W/RhRKp/sRRWIRuNByxbVJU=
X-Received: by 2002:a1c:abc3:: with SMTP id u186mr1802799wme.42.1587425958820; Mon, 20 Apr 2020 16:39:18 -0700 (PDT)
MIME-Version: 1.0
References: <20200417101932.GA2035@wakko.flat11.house> <CAMOjQcF10Ceh=O1-s58Kw_j_hekbCnfmQ9sMZGZiwvhDdbg2bA@mail.gmail.com>
In-Reply-To: <CAMOjQcF10Ceh=O1-s58Kw_j_hekbCnfmQ9sMZGZiwvhDdbg2bA@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 20 Apr 2020 19:39:07 -0400
Message-ID: <CAHbrMsBCeg+3wDcbAJk=KZC1y0RPtLjznst2NVSDJQVSRL84XA@mail.gmail.com>
To: Eric Orth <ericorth=40google.com@dmarc.ietf.org>
Cc: Alessandro Ghedini <alessandro@ghedini.me>, dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000006b4b3105a3c16870"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/FeVhFCfPlqz178Nea6-_S_UuWk4>
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: Mon, 20 Apr 2020 23:39:24 -0000
On Mon, Apr 20, 2020 at 7:30 PM Eric Orth <ericorth= 40google.com@dmarc.ietf.org> wrote: > > > On Fri, Apr 17, 2020 at 6:20 AM Alessandro Ghedini <alessandro@ghedini.me> > wrote: > >> Hello, >> >> First off, I have started implementing support for SVCB and HTTPSSVC as >> part of >> the dnspython library [0] and I'd be interested in doing some interop >> testing >> with other people's implementations. >> >> I also have a few comments/questions about the draft, apologies if they >> have >> already been discussed in the past (haven't been following the draft from >> the >> start). >> >> 1. For interop testing purposes it would be very helpful if the draft >> listed >> commonly agreed upon code-points for the new RR types. Ideally in the >> form of an >> official early assignment from IANA, but if that's not possible picking a >> couple >> of codepoints at random from the "private use" range would also be >> helpful. In >> my implementation I'm currently using "65481" for SVCB and "65482" for >> HTTPSSVC. >> >> 2. The structure of the draft is a bit odd, as it lists a bunch of >> examples >> before introducing any of the records. This was a bit confusing to me, so >> I'd >> suggest moving sections 1.5 and 1.6 _before_ the examples (that is, >> immediately >> after the introduction). It might also be a good idea to just move the >> examples >> to an Appendix instead. >> >> 3. Would it make sense to move the ESNI/ECHO config paramenter to the >> ESNI/ECHO >> draft instead? This way the DNS draft wouldn't need to depend on the ESNI >> draft >> (so e.g. if ESNI ends up taking longer, this draft could be published >> without >> having to wait for it). >> >> 4. What is the point of differentiating between AliasForm and >> ServiceForm? Like, >> couldn't the draft just say that the SvcFieldValue is an optional field >> and be >> done with that? It seems like not having to explicitly differentiate the >> two >> cases would simplify the draft a bit without sacrificing much, though I >> might >> be missing something. >> > > I think the stronger distinction makes it easier to describe the required > behavior differences. Much simpler to just say things like don't mix both > forms in the same response, and to ignore non-alias if any aliases are > present, than to make more detailed descriptions about what specific > optional contents are allowed to be mixed or not to accomplish the same > thing. > > >> >> 5. Section 2.1.1 says >> >> The presentation format for SvcFieldValue is a whitespace-separated >> list of elements representing a key-value pair, with an absent value >> or "=" indicating an empty value. >> >> It took me longer than I'd like to admit to understand the "with an >> absent value >> or "=" indicating an empty value" part. I'd suggest rewording that >> paragraph to >> something like: >> >> The presentation format for SvcFieldValue is a whitespace-separated >> list of >> key=value pairs (e.g. "key123=value1 keys456=value2"). When the value, >> or >> both the value and the "=" are omitted, the value should be >> interpreted as >> being empty. >> >> Or something better :) >> >> 6. In Section 2.2 it says (in reference to param field values): >> >> o an octet string of the length defined by the previous field. >> >> It might be good to say here that the format of this octet string is >> defined >> according to the corresponding SvcParamKey, and then reference section 6 >> for >> ths currently defined keys. The same applies for section 2.1.1 for the >> presentation format. >> >> 7. Section 4.3 says: >> >> All DNS servers SHOULD treat the SvcParam portion of the SVCB RR... >> >> Should it be SvcFieldValue instead of SvcParam? "SvcParam" is not >> mentioned >> anywhere else. >> >> 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. > So the client gets an HTTPSSVC result for cname.cdn-b.example but only > queried A/AAAA for www.xample.net, so without hints, the client will have > to do an extra set of A/AAAA queries for cname..cdn-b.example. > > >> >> 9. Speaking of multi-CDN, AFAICT the problem is mentioned only once in >> the whole >> draft and only in relation to ESNI. However this is not ESNI-specific and >> also >> affects e.g. HTTP/3 as per the example above. So I think it would be >> useful to >> go into a little more detail on this. >> >> 10. Section B.2: s/pther/other/ >> >> Cheers >> >> [0] https://github.com/rthalley/dnspython/pull/452 >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
- [DNSOP] Comments on draft-ietf-dnsop-svcb-httpssv… Alessandro Ghedini
- Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-htt… Mark Andrews
- Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-htt… Eric Orth
- Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-htt… Ben Schwartz
- Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-htt… Ben Schwartz
- Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-htt… Eric Orth
- Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-htt… Ben Schwartz
- Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-htt… Alessandro Ghedini
- Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-htt… Mark Andrews
- Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-htt… Alessandro Ghedini
- Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-htt… Ben Schwartz