Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

Paul Hoffman <paul.hoffman@icann.org> Thu, 08 September 2022 15:06 UTC

Return-Path: <paul.hoffman@icann.org>
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 F1DA1C152718 for <dnsop@ietfa.amsl.com>; Thu, 8 Sep 2022 08:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 3ePJOK5xOLxO for <dnsop@ietfa.amsl.com>; Thu, 8 Sep 2022 08:06:48 -0700 (PDT)
Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72037C1527A5 for <dnsop@ietf.org>; Thu, 8 Sep 2022 08:06:48 -0700 (PDT)
Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa4.dc.icann.org (8.17.1.5/8.17.1.5) with ESMTPS id 288F6kqq013201 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <dnsop@ietf.org>; Thu, 8 Sep 2022 15:06:46 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.29; Thu, 8 Sep 2022 08:06:45 -0700
Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0986.029; Thu, 8 Sep 2022 08:06:45 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
Thread-Topic: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)
Thread-Index: AQHYuMJTTKMGJ4SZhEuw4WRofe80J63CgwuAgAFBfoCAA73TAIABq9kAgABP4gCAAKQwgIAAP44AgAqhVACAABUmAIAAHOsAgAAH7oCAAB+jgIAADVuAgADC5oA=
Date: Thu, 08 Sep 2022 15:06:45 +0000
Message-ID: <A222DD8A-517D-4D7C-AB8E-2EEB99FF1C7E@icann.org>
References: <CAH1iCiqzeZORDmbE+XMs1wt6YZKYFZWnsnrvN8fbLHpFXEfDfw@mail.gmail.com> <CAHbrMsDSbDapPFFfhU1iyi5BpEjb8NA7WXz+1pu78dGnuVkNzg@mail.gmail.com> <CAH1iCiojyT47nvNqeCkz8X4ueY0y_fp11BNEoV6WMuWx639_Dg@mail.gmail.com> <CAH1iCipRjnvs71iiK1aaMKj98P65-NqKSL4+XfmMA_MsU9_JNg@mail.gmail.com> <CAHw9_iJg7yTECPbPvSNxac21My4SqPjMjhYS4tFRWBzFmjkLjg@mail.gmail.com> <CAH1iCipoo2u2h8XtJp8iwrg-bonMC785RehC3bVzbMKaLv+Kpg@mail.gmail.com> <0203FD85-487D-4B64-88BF-818B5BE0BC70@apple.com> <CAHbrMsCZSkakKvnxTsqQ0JmywNAHwVC1DyN0aVJ72sH7fgy6pA@mail.gmail.com> <CAHw9_iLNSnwUyZomkQ49Czhk-evy1Z4LjL7CfVhP7EFvZpBh5A@mail.gmail.com> <Yxk1Iikv8XazQa7o@straasha.imrryr.org> <Yxk7ycs0274UMSSh@straasha.imrryr.org> <0A4F52A8-378F-4222-9E5A-041A82E97C79@icann.org> <CAH1iCiriUcqprYj+LJGoo40o-dRsYyGmOFU_6VWbTXBt8+xnJw@mail.gmail.com>
In-Reply-To: <CAH1iCiriUcqprYj+LJGoo40o-dRsYyGmOFU_6VWbTXBt8+xnJw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: True
Content-Type: multipart/signed; boundary="Apple-Mail=_E59B2ACD-69CB-47E5-9359-674FB464F69F"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1 definitions=2022-09-08_10,2022-09-08_01,2022-06-22_01
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/okYFz115vxgZ26u4oi1Iq3FTjSQ>
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: Thu, 08 Sep 2022 15:06:49 -0000

On Sep 7, 2022, at 8:29 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
> > Once SVCB resolution has concluded, whether successful or not,
> > +if at least one AliasMode record was processed,
> > 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.)
> 
>> What happens under the current wording, before the addition above? That is, if no AliasMode record was processed, is the addition along the lines of "you can only add this if you have it, and if no AliasMode record was processed, you don't have it"? Or does the addition solve the problem "if no AliasMode record was processed, the thing you append will be harmful"?
>> 
> Yes.
> 
> If no AliasMode record was processed, then $QNAME would be the origin name PLUS the prefix(es) of type attrleaf ( underscore thingies). Those won't be legitimate A/AAAA owner names (and shouldn't exist), and if a client did that it would be harmful (to the client), at least a little bit harmful (trying something that won't work.)

If this proposed change is only for something that is a bit harmful to the client (trying something that won't work), then I don't think this reaches the bar for making a change after IETF and IESG evaluation. The amount of process work that is necessary to make this technical change far outweighs the advantage to clients who are unaware of the problem that this thread has exposed.

A draft with a discussion of this one problem would go a long way to alerting client authors of this problem. The same draft could also talk about the other issues that sparked this larger thread. Such a draft is not limited to "change this sentence to that": it could have a discussion of the various things that client developers are discovering.

--Paul Hoffman