Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-02.txt

Eric Orth <ericorth@google.com> Tue, 05 January 2021 17:00 UTC

Return-Path: <ericorth@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 6F9F93A104B for <dnsop@ietfa.amsl.com>; Tue, 5 Jan 2021 09:00:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.971
X-Spam-Level:
X-Spam-Status: No, score=-17.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, 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=unavailable 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 SyqVVYEQxFra for <dnsop@ietfa.amsl.com>; Tue, 5 Jan 2021 09:00:49 -0800 (PST)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 F0D0A3A1047 for <dnsop@ietf.org>; Tue, 5 Jan 2021 09:00:48 -0800 (PST)
Received: by mail-lf1-x132.google.com with SMTP id s26so74127933lfc.8 for <dnsop@ietf.org>; Tue, 05 Jan 2021 09:00:48 -0800 (PST)
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=s9qOpM1OzoyCRlynbn+XOAiRsWhUHQd2dqnj5Zx1TaY=; b=eDqfeo139xTuKnA8PQfV9vpGN6pVgfZVl3IOd2+edRaVnsxBbDSqsLgkvdyBRlkigy 5jMl0DGcKL22DU379/x08w1iR1Eer5t/l6r2e/ulLMeaa4x2sJibgZAenmFDzWkwR64h eN89IBSiytB9hXxttllADncsIdFj0LVa8+zGG++FhReV025AVlappMf2PLtjt9LA8Pdk JOnULQzlQF6GGoQDZb6RdSSmQQYfpORYDqdk7BhfXXOHZSzZNKn0BnzR3vGr/kLA3cuQ TOaYKzsWcC8qcb2/yiG7+kKEG6XX5P996hA983YBzXi63JAfhdUsiE/QpSXOqWiFd6I8 sV7g==
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=s9qOpM1OzoyCRlynbn+XOAiRsWhUHQd2dqnj5Zx1TaY=; b=QAlDmhlwZBwfK7MfoOrpNer6guUgfYiL366gF//8e5YKFVAw9wTqrXqm8MJVNM7DNm TSt8UJ/Y9nABJDtzyzIMIjDOX2jfOTMyr4a97TOjlgFWx8jf+PaiZNH84zd5tLF73qSr pzOBvSa/st+E8DQUtN++aOOueUgtdw2joj1M+sfhMliSdyMuhfxYpYgCW6M9Ego65SGW i0xgvm4qVJbPwfevWI0DoQ5oKvho/qQfQJivKlW1XukPBITYBz+OieVlz25eRlvF949e N+KkANS4u8DSQgp7ED+ifW+NmXquks3YphixrtupLB6mjPrhJBuKPoO7IZLJNZLDf8pt blDw==
X-Gm-Message-State: AOAM530CImBHlpLgU7XIyRywhXALfu2KSZs37dMefBBU47M1UXaAKm8Q vGRf0ty+atQk/hyRmYIS8mN9rNRjUPulKPOmooUBtw==
X-Google-Smtp-Source: ABdhPJwXX5x+pjaRASDZvLghUm+s67oiRXyI1T5E4GAnwi5z6VIc8LCLKtjr3rRnOUXemnJyaUlbsP1siEF7Py8tJrs=
X-Received: by 2002:a05:6512:20d4:: with SMTP id u20mr110121lfr.116.1609866046077; Tue, 05 Jan 2021 09:00:46 -0800 (PST)
MIME-Version: 1.0
References: <160435342340.5690.11246183519764836508@ietfa.amsl.com> <CAHbrMsCfxhv_fiSMuZNb+Rx=p_oa-Z682sAj8D4y7YkAf0=Lgg@mail.gmail.com> <500fe764-612b-a7d6-3d2c-efbf02d1b75c@nic.cz>
In-Reply-To: <500fe764-612b-a7d6-3d2c-efbf02d1b75c@nic.cz>
From: Eric Orth <ericorth@google.com>
Date: Tue, 5 Jan 2021 12:00:35 -0500
Message-ID: <CAMOjQcF+hTgYZ6WZrwjL=yARHJvkZZJnreGiKczB2xNu3oYU4w@mail.gmail.com>
To: "libor.peltan" <libor.peltan@nic.cz>
Cc: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d04c4705b82a258e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/tl3BdfGchF0HJhlx2wpmes1RM1c>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-02.txt
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: Tue, 05 Jan 2021 17:00:51 -0000

On Wed, Dec 30, 2020 at 4:39 AM libor.peltan <libor.peltan@nic.cz> wrote:

> Hi Ben, all,
> i'd like to ask for some clarification of expected Authoritative server
> behaviour around Alias SVCB records:
>
> 1) when there are multiple Alias SVCB records for an owner name, should
> the Authoritative server put targeted records into Additionals for all of
> them, or just pick one?
> (Section 4.1 says "authoritative DNS servers SHOULD return A, AAAA, and
> SVCB records in the Additional Section for any in-bailiwick TargetNames",
> but section 2.4.2 will render it useless with "If multiple are present,
> clients or recursive resolvers SHOULD pick one at random." Which means,
> half (or most) of the additionals will get thrown away.)
>
I believe Additional records would still be considered in the RRSet, and
thus including them would run afoul of a SHOULD in 2.4.2: "SVCB RRSets
SHOULD only have a single resource record in AliasMode."

Whether the authoritative server picks one or does something to reject a
multi-alias config as invalid seems to be up to the server and out of scope
for this spec.

>
> 2) When the TargetName points to an in-bailiwick CNAME, should the
> autoritative server populate the CNAME chain inside the Additional section?
> It seems to me (fortunately :) ), that following such CNAME is only
> required for Recursive resolvers, however e.g. this zone will thus need
> three upstream queries to fetch it all:
> foo 3600 IN SVCB 0 bar
> bar 3600 IN CNAME baz
> baz 3600 IN SVCB 0 . alpn=...
> baz 3600 IN AAAA 1::2
>
> Thanks for your answers,
> Libor
>
> PS: is this e-mail thread the right place to ask for details clarification
> around SVCB features?
> Dne 16. 11. 20 v 7:43 Ben Schwartz napsal(a):
>
> For those who haven't looked at the diff, here are the changes since -01
>       *  Added a Privacy Considerations section
>       *  Adjusted resolution fallback description
>       *  Clarified status of SvcParams in AliasMode
>       *  Improved advice on zone structuring and use with Alt-Svc
>       *  Improved examples, including a new Multi-CDN example
>       *  Reorganized text on value-list parsing and SvcPriority
>       *  Improved phrasing and other editorial improvements throughout
>
> Notably, the normative changes are extremely limited compared to the
> previous draft.  This reflects the authors' view that this draft is
> stabilizing and should be ready for WGLC soon.
>
> Perhaps more important than the changes that were made are the changes
> that were discussed but have not been made:
> * We had an extensive discussion regarding the meaning of TargetName =
> ".", which is currently shorthand for the owner name.  Some suggested
> augmenting this to mean "owner name minus underscore prefix labels", and
> others suggested removing this special-case entirely.  (
> https://github.com/MikeBishop/dns-alt-svc/issues/252)
> * We received a suggestion to ban fallback to non-SVCB connection
> establishment (https://github.com/MikeBishop/dns-alt-svc/issues/256).
> (We clarified the fallback text but did not change the recommendation.)
> * The escaping of ALPNs that contain commas continues to be contentious.
> We received a suggestion to remove support for such ALPNs (
> https://github.com/MikeBishop/dns-alt-svc/issues/268).
>
> In each case, we think that the draft's current text still reflects the
> group's consensus and strikes the right balance.  If you disagree, please
> open a thread on the dnsop list and we will discuss it.
>
> We have one open issue that seems likely to result in a text change (
> https://github.com/MikeBishop/dns-alt-svc/issues/87).  This is a fine
> point regarding the HTTPS user experience if TLS fails, and we are
> soliciting input from experts on those topics.
>
> On Mon, Nov 2, 2020 at 4:44 PM <internet-drafts@ietf.org> wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Domain Name System Operations WG of the
>> IETF.
>>
>>         Title           : Service binding and parameter specification via
>> the DNS (DNS SVCB and HTTPS RRs)
>>         Authors         : Ben Schwartz
>>                           Mike Bishop
>>                           Erik Nygren
>>         Filename        : draft-ietf-dnsop-svcb-https-02.txt
>>         Pages           : 45
>>         Date            : 2020-11-02
>>
>> Abstract:
>>    This document specifies the "SVCB" and "HTTPS" DNS resource record
>>    (RR) types to facilitate the lookup of information needed to make
>>    connections to network services, such as for HTTPS origins.  SVCB
>>    records allow a service to be provided from multiple alternative
>>    endpoints, each with associated parameters (such as transport
>>    protocol configuration and keys for encrypting the TLS ClientHello).
>>    They also enable aliasing of apex domains, which is not possible with
>>    CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP
>>    origins.  By providing more information to the client before it
>>    attempts to establish a connection, these records offer potential
>>    benefits to both performance and privacy.
>>
>>    TO BE REMOVED: This document is being collaborated on in Github at:
>>    https://github.com/MikeBishop/dns-alt-svc [1].  The most recent
>>    working version of the document, open issues, etc. should all be
>>    available there.  The authors (gratefully) accept pull requests.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-02
>> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-02
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-02
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
> _______________________________________________
> DNSOP mailing listDNSOP@ietf.orghttps://www.ietf.org/mailman/listinfo/dnsop
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>