Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)
Warren Kumari <warren@kumari.net> Wed, 31 August 2022 13:25 UTC
Return-Path: <warren@kumari.net>
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 AD71EC14CE30 for <dnsop@ietfa.amsl.com>; Wed, 31 Aug 2022 06:25:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTYcOskh6AxP for <dnsop@ietfa.amsl.com>; Wed, 31 Aug 2022 06:25:28 -0700 (PDT)
Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2F0AC14CE44 for <dnsop@ietf.org>; Wed, 31 Aug 2022 06:25:28 -0700 (PDT)
Received: by mail-il1-x12f.google.com with SMTP id k2so210822ilu.9 for <dnsop@ietf.org>; Wed, 31 Aug 2022 06:25:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; h=cc:to:subject:message-id:date:in-reply-to:from:references :mime-version:from:to:cc; bh=1CjfcqS0TDtbmmLVhfMtj/xsMcUWDi2tDOLZIxgBmwo=; b=CjPnmeDhpl4jSp9NGluOmfmC6blWHIMxE+BMZatQHV2Wx37wSbY6uJzEjAj8XaBCDp NFP+OHsBtWf29/ChTWVQzHesbxZt5cWfAkdrNbtiepyW5JUinURinLQ8FlfOl0ot9hUj ZNf7VEspJ2FuNxK82G/OHAnOkDHSWZN0BtLUVjGXZvttbF6CzKJgMnuU7/Hd3ZFmtfcQ vKzA0EkzOElc6hm2aDQibJX7ngBJh8LH0BpdVsqO3Mxp4THCByYjO/pbbj7mZ1wlE4E/ nC3obsUJgZ4OBzbTnxnCteq3RQqL9/h6RT21OQd5L3LuJ49x8HriK5bj52+5bYcpEmo3 lzhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:in-reply-to:from:references :mime-version:x-gm-message-state:from:to:cc; bh=1CjfcqS0TDtbmmLVhfMtj/xsMcUWDi2tDOLZIxgBmwo=; b=QfydvbZV7tX2islQaQsvWniM8+eV1rRUAmd/iW0dhs5FXdiLkkGTnlT5ZFBqfxCHgw xRVhnhS3HIOgO7nQzV2QUmZDfstlnorDxs9re78J1VGYtXdYbzusMs8smcAwkg7aVlk6 7g3VQ0xTqohvVCB6r5wNKQmGVHPqjS6XQrs1i7IRI1qc9iWx9Yt1CcJo7o/E3XzXfauN JTVqhlUJXJQ6JapRR/wa034iqK/qnzDDxcIZ1EAsoJZNVXuwyWQdtwlidiSGkQpZ+iGY rBL6Hva6z4q3ouNMf2u34IsKDugHV/Z3LpC9jxwY26rE9ZCzvO4ANyUton8Cb1c+2p8B +tfA==
X-Gm-Message-State: ACgBeo0Vz6SEAJ0KR9g8Ku31br+jDhKyVDc1Gcj2T/UokHhSm7Sprcxq XEwpPGudwTQUXWzl/+tOCJ8B9xRHKORkuW9+2edEnsGTRWk=
X-Google-Smtp-Source: AA6agR6xPWjAj5jrZKbwD9ISyK2c5rhVMxU/oOv7qLIXNIEFX/3dn74I+3pJV1l2rf6RRJu3kAHC/NBJJ+NmURwXDWY=
X-Received: by 2002:a92:d70e:0:b0:2e8:8ac8:4f3a with SMTP id m14-20020a92d70e000000b002e88ac84f3amr14461178iln.158.1661952327228; Wed, 31 Aug 2022 06:25:27 -0700 (PDT)
Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Wed, 31 Aug 2022 06:25:26 -0700
Mime-Version: 1.0
X-Superhuman-Draft-ID: draft00a29afacb317d5b
References: <CAHw9_iKZJndu1100LBU3TiuhF9ACb0As2deA1oZWD2eA46tBbA@mail.gmail.com> <CAH1iCiqryY=u6MN2mkf7krHLmc7TQkoDaXe0k=ZZ+0e9uiMb-Q@mail.gmail.com> <YwaQrnoA3hifxCQW@straasha.imrryr.org> <CAMOjQcEcKQSWvb_LqmfkGwZ2dt_561jLZxHTMuMO0pMy2s9mbw@mail.gmail.com> <CAH1iCirnWdDY0p2-grQKN3PQWOM=JLevxbNskFFEzGwHvisGZA@mail.gmail.com> <B024358C-77FD-4E63-8E18-1CBCEA6C6B14@icann.org> <CAH1iCiry3VDS+dM+wEkPH5a_TSt5pEddxPjKOhL9_M20e_dR0A@mail.gmail.com> <8B970775-22CF-403B-9B8A-84DCC0932D76@icann.org> <CAHbrMsC_RO1J6qp_yOWOc3P4zpZ-cOCB6adXRwjoSQP7_yrWug@mail.gmail.com> <CAH1iCiqzeZORDmbE+XMs1wt6YZKYFZWnsnrvN8fbLHpFXEfDfw@mail.gmail.com> <CAHbrMsDSbDapPFFfhU1iyi5BpEjb8NA7WXz+1pu78dGnuVkNzg@mail.gmail.com> <CAH1iCiojyT47nvNqeCkz8X4ueY0y_fp11BNEoV6WMuWx639_Dg@mail.gmail.com> <CAH1iCipRjnvs71iiK1aaMKj98P65-NqKSL4+XfmMA_MsU9_JNg@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
X-Mailer: Superhuman Desktop (2022-08-30T22:05:55Z)
X-Superhuman-ID: l7hnhqeo.152eb324-e375-4dac-9944-a728de96a45e
In-Reply-To: <CAH1iCipRjnvs71iiK1aaMKj98P65-NqKSL4+XfmMA_MsU9_JNg@mail.gmail.com>
Date: Wed, 31 Aug 2022 06:25:26 -0700
Message-ID: <CAHw9_iJg7yTECPbPvSNxac21My4SqPjMjhYS4tFRWBzFmjkLjg@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: draft-ietf-dnsop-svcb-https.all@ietf.org, "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001934ab05e7896ea7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xwi18XB4Tn3LGlnuRoAodras0z4>
Subject: Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 31 Aug 2022 13:25:32 -0000
On Wed, Aug 31, 2022 at 4:39 AM, Brian Dickson < brian.peter.dickson@gmail.com> wrote: > Here are some proposed text changes, per Warren's invitation to send text: > Um, no. Warren said: "can we craft a sentence (or possibly two) which only clarify what is already written?". This is a significantly larger set of changes than that. The Section 3 changes in particular are (IMO) much more than a clarification. These may or may not be good changes, but anything approaching that level of change would have to be in a -bis document… W > In section 1.2, change: > > 2. TargetName: The domain name of either the alias target (for > AliasMode) or the alternative endpoint (for ServiceMode). > > to: > > 2. TargetName: Either the domain name of the alias target (for > AliasMode) or the host name of the alternative endpoint (for > ServiceMode). > > In section 2.4.2, change: > > As legacy clients will not know to use this record, service operators > will likely need to retain fallback AAAA and A records alongside this > SVCB record, although in a common case the target of the SVCB record > might offer better performance, and therefore would be preferable for > clients implementing this specification to use. > > to: > > As legacy clients will not know to use this record, service operators > will likely need to retain fallback AAAA and A records at the service > name, > although in a common case the target of the SVCB record > might offer better performance, and therefore would be preferable for > clients implementing this specification to use. > > > In section 2.4.3, change: > > In ServiceMode, the TargetName and SvcParams within each resource > record associate an alternative endpoint for the service with its > connection parameters. > > to: > > In ServiceMode, the TargetName and SvcParams within each resource > record associate an alternative endpoint for the service with its > connection parameters. The TargetName MUST be a host name > (as defined in [DNSTerm].) > > In section 3, the following changes are proposed; they introduce a new > term LASTNAME to be used to disambiguate the $QNAME reference so as to > remove ATTRLEAF prefixes from the appended target: > > > 1. Let $QNAME be the service name plus appropriate prefixes for the > scheme (see Section 2.3). > > becomes: > > 1. Let $QNAME be the service name plus appropriate prefixes for the > scheme (see Section 2.3). Let $LASTNAME be the service name without > any prefixes. > > > > 3. If an AliasMode SVCB record is returned for $QNAME (after > following CNAMEs as normal), set $QNAME to its TargetName > (without additional prefixes) and loop back to step 2, subject to > chain length limits and loop detection heuristics (see > Section 3.1). > > becomes: > > 3. If an AliasMode SVCB record is returned for $QNAME (after > following CNAMEs as normal), set $QNAME to its TargetName > (without additional prefixes), set $LASTNAME to this new $QNAME and > loop back to step 2, subject to > chain length limits and loop detection heuristics (see > Section 3.1). > > > Once SVCB resolution has concluded, whether successful or not, SVCB- > optional clients SHALL append to the priority list an endpoint > consisting of the final value of $QNAME, the authority endpoint's > port number, and no SvcParams. (This endpoint will be attempted > before falling back to non-SVCB connection modes. This ensures that > SVCB-optional clients will make use of an AliasMode record whose > TargetName has A and/or AAAA records but no SVCB records.) > > becomes: > > Once SVCB resolution has concluded, whether successful or not, SVCB- > optional clients SHALL append to the priority list an endpoint > consisting of the final value of $LASTNAME, the authority endpoint's > port number, and no SvcParams. (This endpoint will be attempted > before falling back to non-SVCB connection modes. This ensures that > SVCB-optional clients will make use of an AliasMode record whose > TargetName has A and/or AAAA records but no SVCB records.) > > If the client is SVCB-optional, and connecting using this list of > endpoints has failed, the client now attempts to use non-SVCB > connection modes. > > becomes: > > If the client is SVCB-optional, and connecting using this list of > endpoints has failed, the client MAY attempt to use non-SVCB > connection modes, using the origin name (without prefixes), > > the authority endpoint's port number, and no SvcParams. > > > One additional suggested addition to the end of section 3.1 is: > > If DNS responses are cryptographically protected, and at least > one HTTPS AliasMode record has been received successfully, > clients MAY apply Section 9.5 (HSTS equivalent) restrictions > even when reverting to non-SVCB connection modes. Clients > > also MAY treat resolution or connection failures subsequent > > to the initial cryptographically protected AliasMode record > > as fatal. > > [Brian's note: this last would provide some guidance to implementers of > clients: a signed HTTPS AliasMode record is a strong signal that the DNS > operator is discouraging fallback, albeit at a "MAY" level.] > > NB: The 2.4.3 change could be removed as it is mostly independent, as > could the last addition to 3.1. > The 1.2 change is very minor, is not too important but presents a succinct > clarification on the hostname vs domain name thing. > The 2.4.2 change and section 3 changes together are fixes for the > prefix/no-prefix issue (which was basically a scrivener's error, and does > not change the semantics at all.) They should stay or go as one unit. > > Brian > > On Tue, Aug 30, 2022 at 12:08 AM Brian Dickson <brian.peter.dickson@gmail. > com> wrote: > >> >> >> On Sat, Aug 27, 2022 at 3:00 PM Ben Schwartz <bemasc@google.com> wrote: >> >>> >>> >>> On Fri, Aug 26, 2022 at 10:49 PM Brian Dickson <brian.peter.dickson@ >>> gmail.com> wrote: >>> >>>> >>>> Fail fast may not be appealing, but in some (probably the majority of) >>>> cases, it may be the most correct option. >>>> >>>> It may also be the case that the zone owner knows whether this is the >>>> case. >>>> I think it is much more likely that explicitly declaring the situation >>>> (if known) is more useful than having several billion clients independently >>>> attempting to infer whether the first option will even work, let alone >>>> provide a useful alternative to the second or third. >>>> >>> >>> In fact, there is one way for the zone owner to disable fallback: enable >>> ECH. Fallback is not compatible with ECH, so ECH-aware clients will >>> disable fallback when the ServiceMode records contain ECH. >>> >>> >> Wait, what? >> >> This whole discussion was raised from the perspective of zone owners >> publishing AliasMode apex records. >> Those owners would not be operating the CDN, which is the whole point of >> using a CNAME or AliasMode. >> I.e., the zone owner would be the one wanting to disable fallback, but >> would not be in a position to do what you suggest. >> >> The domain's contents are served via a CDN, where the CDN requires >> delegation of control, most often with CNAME (or AliasMode at the apex). >> The ServiceMode records are placed on the CDN operated zone (in order to >> avoid the first connection to establish the AltSvc stuff). >> >> The AliasMode record cannot be combined with ECH, since no SvcParams are >> allowed. The zone owner is not using ServiceMode, that is the declared >> assumption. >> >> If that (ECH) is the only way to disable fallback, that's what the >> focused discussion needed to elicit, and I think some slight adjustments >> are needed to at least facilitate zone owners preventing fallback. The >> mechanism doesn't need to be added to the draft, but likely would get put >> into a separate draft or a -bis document. However, there needs to be some >> daylight between the fallback method and the mandatory SVCB/HTTPS >> components, in order to allow for that development. >> >> BTW, the concern is less about singleton zone owners than it is about >> large scale integrated DNS management of zones in order to accommodate CDN >> usage. >> >> Note also, this issue is not strictly limited to vertical integration >> among products/services of the DNS operator; there are large scale >> inter-provider (DNS and other services) open partnerships (controlled by >> their mutual customers) that have need for the programmatic ability to >> assign CDNs and enable/disable fallback (if fallback is part of the >> specification). >> (For those interested, the not-yet-an-IETF standard for interoperability >> between DNS and service providers is Domain Connect. The intent is to >> revive the draft for that, which previously lived in the REGEXT WG.) >> >> I think converting the fallback in the draft into MAY, and having active >> discussions, dev, test, and deployment on a voluntary basis outside of the >> scope of the current draft, is the fastest path to solving the "no >> fallback" signaling issue, and to getting the draft published (with a few >> minor tweaks). >> >> I'll review the other comments, as well as Warren and Viktor's recent >> messages, and see if I can come up with some proposed text to make very >> limited changes to the draft. >> >> Brian >> >
- [DNSOP] Questions / concerns with draft-ietf-dnso… Warren Kumari
- Re: [DNSOP] [Ext] Questions / concerns with draft… Paul Hoffman
- Re: [DNSOP] [Ext] Questions / concerns with draft… Warren Kumari
- Re: [DNSOP] Questions / concerns with draft-ietf-… Brian Dickson
- Re: [DNSOP] Questions / concerns with draft-ietf-… Stephen Farrell
- Re: [DNSOP] Questions / concerns with draft-ietf-… Martin Thomson
- Re: [DNSOP] Questions / concerns with draft-ietf-… Stephen Farrell
- Re: [DNSOP] Questions / concerns with draft-ietf-… Viktor Dukhovni
- Re: [DNSOP] Questions / concerns with draft-ietf-… Eric Orth
- Re: [DNSOP] Questions / concerns with draft-ietf-… Viktor Dukhovni
- Re: [DNSOP] Questions / concerns with draft-ietf-… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Paul Hoffman
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Eric Orth
- Re: [DNSOP] [Ext] Questions / concerns with draft… Paul Hoffman
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Ben Schwartz
- Re: [DNSOP] [Ext] Questions / concerns with draft… Viktor Dukhovni
- Re: [DNSOP] [Ext] Questions / concerns with draft… Ben Schwartz
- Re: [DNSOP] [Ext] Questions / concerns with draft… Viktor Dukhovni
- Re: [DNSOP] [Ext] Questions / concerns with draft… Tommy Pauly
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Ben Schwartz
- Re: [DNSOP] [Ext] Questions / concerns with draft… Erik Nygren
- Re: [DNSOP] [Ext] Questions / concerns with draft… Viktor Dukhovni
- Re: [DNSOP] [Ext] Questions / concerns with draft… Warren Kumari
- Re: [DNSOP] [Ext] Questions / concerns with draft… Viktor Dukhovni
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- [DNSOP] HSTS on receiving a signed HTTPS record (… Martin Thomson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Warren Kumari
- Re: [DNSOP] Questions / concerns with draft-ietf-… Viktor Dukhovni
- Re: [DNSOP] [Ext] Questions / concerns with draft… Paul Hoffman
- Re: [DNSOP] HSTS on receiving a signed HTTPS reco… Eric Orth
- Re: [DNSOP] HSTS on receiving a signed HTTPS reco… Brian Dickson
- Re: [DNSOP] HSTS on receiving a signed HTTPS reco… Eric Orth
- Re: [DNSOP] [Ext] Questions / concerns with draft… Tommy Pauly
- Re: [DNSOP] HSTS on receiving a signed HTTPS reco… Ben Schwartz
- Re: [DNSOP] [Ext] Questions / concerns with draft… Ben Schwartz
- Re: [DNSOP] [Ext] Questions / concerns with draft… Warren Kumari
- Re: [DNSOP] [Ext] Questions / concerns with draft… Viktor Dukhovni
- Re: [DNSOP] [Ext] Questions / concerns with draft… Viktor Dukhovni
- Re: [DNSOP] [Ext] Questions / concerns with draft… Paul Hoffman
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Martin Thomson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Viktor Dukhovni
- Re: [DNSOP] [Ext] Questions / concerns with draft… Paul Hoffman
- Re: [DNSOP] [Ext] Questions / concerns with draft… Viktor Dukhovni
- Re: [DNSOP] [Ext] Questions / concerns with draft… Paul Hoffman
- Re: [DNSOP] [Ext] Questions / concerns with draft… Erik Nygren
- Re: [DNSOP] [Ext] Questions / concerns with draft… Warren Kumari
- Re: [DNSOP] [Ext] Questions / concerns with draft… Erik Nygren
- Re: [DNSOP] [Ext] Questions / concerns with draft… Erik Nygren