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

Ben Schwartz <bemasc@google.com> Thu, 07 May 2020 01:32 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 B19513A0E0D for <dnsop@ietfa.amsl.com>; Wed, 6 May 2020 18:32:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 66S_x8GEA5qM for <dnsop@ietfa.amsl.com>; Wed, 6 May 2020 18:32:41 -0700 (PDT)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 CF5AF3A0E0F for <dnsop@ietf.org>; Wed, 6 May 2020 18:32:40 -0700 (PDT)
Received: by mail-wm1-x32d.google.com with SMTP id z6so4841759wml.2 for <dnsop@ietf.org>; Wed, 06 May 2020 18:32:40 -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=XBlneT7QA562ap91OrFMjqAcJqpjCXGZWfoQU+nj37k=; b=QceYSIRQbPlJ+yjBl6SSlJCDhQd9lH/x5dymO+Zv62CvCCRRFm2d1qEaW/63r1vK74 I2329lLfo8nvMzRx2lyjCGfHcqJl0hzfIeHh+KvoL0mAt+9W6cVMC/Lv29QLz1LQSYn3 Qf47d9lDFpNeuLZg4wC8i3bi2+uhBpEWn2kaD1OcHHV2ytcxbtIMv7sefQVNeyLC9evb Dd4OyVLXBqHd4uzWhG+W0bDYXLYu7X7ae5t9IQdOKWHfh416k/FXSk2sB3+8Q+5kVB1O xRxA0k8MBqmd9ymLvVcyfDbE12vwaEVBOPrNYrxn5y0fucGzxlB/BSxzP7PqiEG+RBM+ af+w==
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=XBlneT7QA562ap91OrFMjqAcJqpjCXGZWfoQU+nj37k=; b=K/2KecNNQlufnjzOLCLeEBL2E+xen0US91s8IEIsGqoSmduQQaB6Bh62GcYrZ70cBM hil/XnZkmfCALAS9YIijQKVSZXo8Bppqb7wXMOXMm4elZKhi0BTVUmzMup7RFgybO1fs x7eicnkzoRKi4HIKIULn6iQsG+JHSyPAMWR07TG83pzGoKKihCJ3MNU+S6LgaHaJrsEX 6c+wX2p44Z2ZnibWtnQfpxefaqF7x/p2JAZGAKiNQ70beCaB5B6kAeKT11trt5apdMD7 2GQq77dcbha6qw+zQ8sGVBMTpZRZ2oD3+I61+LKBYu+zMuagLaI4CtsQRqRWtMPxA+ho d+1w==
X-Gm-Message-State: AGi0Puad68Rn8ATUS4J4BAQ4Hil2E/vIWf+4Cb2702UFe7DqMu4KkapE AKiX8ZU6jiia7H0CUclMyd1v4SxldGd8yWad5wud/A==
X-Google-Smtp-Source: APiQypKwJlzeb59lQkAavF32B3qrpGVrcKygHDY0R+4j30vezvBGLQxCb1trv2hA/0Y/BNOJZV/Ie1EGXyk0maS/IKw=
X-Received: by 2002:a05:600c:230f:: with SMTP id 15mr4461963wmo.101.1588815158592; Wed, 06 May 2020 18:32:38 -0700 (PDT)
MIME-Version: 1.0
References: <CAG0m4gSKa5K+KD-hHwk3JGj_JTSZh99bxQW49DZ4dKhQg_fvkg@mail.gmail.com>
In-Reply-To: <CAG0m4gSKa5K+KD-hHwk3JGj_JTSZh99bxQW49DZ4dKhQg_fvkg@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Wed, 6 May 2020 21:32:26 -0400
Message-ID: <CAHbrMsAi5uSC60MJ5kG4V5Lb1Npr55KWy1nCp_nrvga-tZu1NA@mail.gmail.com>
To: Dragana Damjanovic <dragana.damjano@gmail.com>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000002f004605a504db52"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qpe60__o-2bkBFZr3i8iritIfg0>
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: Thu, 07 May 2020 01:32:48 -0000

On Wed, May 6, 2020 at 4:18 PM Dragana Damjanovic <dragana.damjano@gmail.com>
wrote:

> I have some minor comments and clarification questions.
>
> 1) in "Example: Protocol enhancements":
>
>> and the key=value pairs indicate that it supports QUIC in addition to
>> HTTPS over TLS
>>
>
> Should  "HTTPS over TLS" be "HTTPS over TCP"? HTTP3 is also HTTPS over TLS
>

You're right; that would be clearer.  Change proposed at
https://github.com/MikeBishop/dns-alt-svc/pull/146.


> 2) Clarification question: Can  SvcDomainName point to another AliasForm
> record? As I understand it, it cannot.
>

Technically, SvcDomainName doesn't point to a record.  It provides a domain
name, and the recursive resolver should perform some queries to that name.
The QTYPE of those queries can vary depending on context.

If the SVCB record is in AliasForm (priority=0), the resolver should query
A, AAAA, and SVCB for the SvcDomainName.  If the SVCB record is in
ServiceForm, the resolver should query A and AAAA records on the
SvcDomainName.  All of these queries follow CNAMEs as per usual.

It can point to a CNAME that points to an AliasForm record.
>

>From SVCB's perspective, CNAME is completely transparent.

...

> I am just wondering if the description in "Client behavior" and "DNS
> Server Behavior" should be more precise and mention this constraint and
> also the limit for a chains of CNAME and SVCB of 8?
>

The chain length limit has been discussed at some length here without
consensus.  The current draft says

>  Chains of consecutive SVCB and CNAME records SHOULD be limited to (8?)
prior to reaching terminal address records.

I suspect that we are going to end up removing this number entirely, and
leaving the choice of limit to implementations.  This isn't ideal for
interoperability, but it seems to be no worse than the status quo with
CNAME.

3) Proxies should not use SVCB/HTTPSSVC.. section "Clients using a Proxy"
> should say that explicitly. (To make useful for a proxy to use
> SVCB/HTTPSSVC records, there should be a way to communicate back to the
> client about that SVCB/HTTPSSVC parameters. This does not exist at the
> moment and will add a delay in some cases, etc.)
>

I agree that transport proxies cannot issue SVCB or HTTPSSVC
queries, because they do not know what protocol/scheme is running over the
transport.  Tracked at https://github.com/MikeBishop/dns-alt-svc/issues/147.

4) If no-default-alpn is present the alpn parameter must be present as
> well, otherwise the "ALPN set" is empty?
>

Correct.

5) A clarification question: In the section "ipv4hint and ipv6hint":
>
>> An empty list of addresses is invalid.
>
> Empty hints will not mean that the record is malformed, i.e. it is not a
> fatal error that will make the whole record invalid?
>

An RR with an empty IP hint is malformed, in presentation format or wire
format.

6) Nit:
>
>> As discussed in {{client-behavior}}, clients MUST be able fetch
>> additional information that is required to use
>>
>
> s/MUST be able fetch/MUST be able to fetch
>

Thanks.  Fixed!


>
> dragana
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

On Wed, May 6, 2020 at 4:18 PM Dragana Damjanovic <dragana.damjano@gmail.com>
wrote:

> I have some minor comments and clarification questions.
>
> 1) in "Example: Protocol enhancements":
>
>> and the key=value pairs indicate that it supports QUIC in addition to
>> HTTPS over TLS
>>
>
> Should  "HTTPS over TLS" be "HTTPS over TCP"? HTTP3 is also HTTPS over TLS
>
>
> 2) Clarification question: Can  SvcDomainName point to another AliasForm
> record? As I understand it, it cannot. It can point to a CNAME that points
> to an AliasForm record.
> The descriptions of the server and client behavior sections do not mention
> this. Should they mention this again?
> I am just wondering if the description in "Client behavior" and "DNS
> Server Behavior" should be more precise and mention this constraint and
> also the limit for a chains of CNAME and SVCB of 8?
>
>
> 3) Proxies should not use SVCB/HTTPSSVC.. section "Clients using a Proxy"
> should say that explicitly. (To make useful for a proxy to use
> SVCB/HTTPSSVC records, there should be a way to communicate back to the
> client about that SVCB/HTTPSSVC parameters. This does not exist at the
> moment and will add a delay in some cases, etc.)
>
> 4) If no-default-alpn is present the alpn parameter must be present as
> well, otherwise the "ALPN set" is empty?
>
> 5) A clarification question: In the section "ipv4hint and ipv6hint":
>
>> An empty list of addresses is invalid.
>
> Empty hints will not mean that the record is malformed, i.e. it is not a
> fatal error that will make the whole record invalid?
>
> 6) Nit:
>
>> As discussed in {{client-behavior}}, clients MUST be able fetch
>> additional information that is required to use
>>
>
> s/MUST be able fetch/MUST be able to fetch
>
> dragana
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>