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
>