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, 05 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 >
- [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-0… internet-drafts
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-htt… Ben Schwartz
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-htt… libor.peltan
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-htt… Eric Orth
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-htt… Ben Schwartz
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-htt… Paul Vixie
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-htt… Ben Schwartz
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-htt… Eric Orth
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-htt… Brian Dickson