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

Ben Schwartz <bemasc@google.com> Tue, 05 January 2021 17:42 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 A2AE23A1057 for <dnsop@ietfa.amsl.com>; Tue, 5 Jan 2021 09:42:30 -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=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 UICTt3OMcuJd for <dnsop@ietfa.amsl.com>; Tue, 5 Jan 2021 09:42:28 -0800 (PST)
Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 3B37E3A105C for <dnsop@ietf.org>; Tue, 5 Jan 2021 09:42:28 -0800 (PST)
Received: by mail-il1-x12e.google.com with SMTP id n9so488867ili.0 for <dnsop@ietf.org>; Tue, 05 Jan 2021 09:42:28 -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=Xp2kLR+LfIQYu/4l7Jl/pVT+YqYn2dP0fnskpBBmBgg=; b=QgYfOut+giJ35H04yq1wI+b3KotIwztMKsZkDZXY2WlSdFJP6yxOUFj05EOnb7R20x HapSFH6X8xpANjGhqO7r5pvTlfIBH9lhO6+/5xocNpi8Nr2FG7JW8F0limZkEZbxxzrF ZvCmc/vHPJOes9k72BBdnXqrdpvBM0qXfqlJB1JPoArOv88LVF+Y0jY8b6T2uQ38ja9m FWO5m4WjR3PZxsEDJvIQKWvd0F+lHY+XLfVWhvEUshFpx12SJHQ+NIkUvLkJ4xV3d/fJ Wc2U8TMFM6aXk+Zgu7MRwa2Z6Z29JETQYu8AK9PWe3Vjz8EeQw4GFoxO9iWpJz5VdHMe H+eQ==
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=Xp2kLR+LfIQYu/4l7Jl/pVT+YqYn2dP0fnskpBBmBgg=; b=WuqqU5e3bduSb0WAWzf3ysPiIcBYsrGnItb6fWpBdZaN++HSj2v4nVlhw7G8kwvTeU Nozvk+P4SOu6PFGYGgkcCESv1/kStXKinnijBw/eQQhd1IRWE3gRzJAAFOCXBuaX76zT B5VIeoyM2VoGkSCDGmsuZYaM0mtwupTBLCRjQArvZJ/IhP9QIqqDM8UM4JMTafKx0Dop zM9UmbMPT0PvBKLgZ7WP2xqLyUDB0OznqS9rpzhs3Tz+XJnfT4llr15LSdeXZ6L+VHty UfESvrgjkCQSrBKTZczZNBQji2k4xcxcChJwTXzXmkkpXQUu294thOxpVX83p8VdktED FTsQ==
X-Gm-Message-State: AOAM5320aktJpOwwljQf9dtUB+lSB9eB6fKw2N6V9udgJa7dVGJIoCeq t4LJHEBQECB2oGErSlabZatEh74OXvQQelouBynEdiuybRtXyQ==
X-Google-Smtp-Source: ABdhPJyf54LK/XWSYXTucXk8CXrlcP5NUVs1MwCbw0eNnJpRECW+hykn8Onsd9NDjG1uAtohlU681lteFwKsTJeZ7iM=
X-Received: by 2002:a05:6e02:104b:: with SMTP id p11mr673557ilj.241.1609868547304; Tue, 05 Jan 2021 09:42:27 -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: Ben Schwartz <bemasc@google.com>
Date: Tue, 5 Jan 2021 12:42:16 -0500
Message-ID: <CAHbrMsDbYZ=JUGN8Cgy9Dhotzd=7Tg5iX6UyNBtEaLP-F6fF8g@mail.gmail.com>
To: "libor.peltan" <libor.peltan@nic.cz>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000ea473905b82abab0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Ez0BeH8wV6gWi3El90_PXeajx1Y>
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:42:31 -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,
>
As Section 2.4.2 says "SVCB RRSets SHOULD only have a single resource
record in AliasMode".  So this "should" not happen.

> should the Authoritative server put targeted records into Additionals for
> all of them, or just pick one?
>
I think the answer is "whatever you would do with CNAME".  Just like CNAME,
there really should only be one record in the RRSet. If you put more than
one AliasMode record in the RRSet ... you're doing it wrong (but the
resolver will still do something reasonable).

...

> 2) When the TargetName points to an in-bailiwick CNAME, should the
> autoritative server populate the CNAME chain inside the Additional section?
>
Yes.  The behavior is not spelled out in detail because it's not an
interoperability requirement, but it is a good optimization.

> 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?
>
Sure.  You can also open a new thread on dnsop.

> 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
>
>