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

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 25 August 2022 23:19 UTC

Return-Path: <ietf-dane@dukhovni.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 E99B8C159495 for <dnsop@ietfa.amsl.com>; Thu, 25 Aug 2022 16:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Lem6NapxEp2B for <dnsop@ietfa.amsl.com>; Thu, 25 Aug 2022 16:19:00 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 3EA7DC14CE3C for <dnsop@ietf.org>; Thu, 25 Aug 2022 16:18:59 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id A759B101541; Thu, 25 Aug 2022 19:18:58 -0400 (EDT)
Date: Thu, 25 Aug 2022 19:18:58 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop@ietf.org
Message-ID: <YwgDYnHiruOr3Kcv@straasha.imrryr.org>
Reply-To: dnsop@ietf.org
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAHbrMsC_RO1J6qp_yOWOc3P4zpZ-cOCB6adXRwjoSQP7_yrWug@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/p5iP38bwt6SBcumreXkLE3FCoB4>
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, 25 Aug 2022 23:19:01 -0000

On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote:

> Relatedly, the results presented by EKR [1] at the most recent DNSOP
> meeting measure that 6.5% of Firefox users are unable to retrieve HTTPS
> records through their local resolver.  To me, this implies that functional
> origin endpoints are likely to be required even if client software gains
> SVCB/HTTPS support.

This is why my suggested client behaviour was cognisant of this impediment.

    - If the client's *initial* SVCB lookup succeeds, *then* fallback is
      no longer an option.

    - If initial SVCB resolution fails (SERVFAIL, timeout, ...)
      then the client behaves as though the SVCB record does not exist.

This results in more predictable behaviour, without optimising for
failure.  If the origin zone directs the service elsewhere, and there
are no last-mile DNS lookup roadblocks, then the protocol becomes
"reliable" (optimises for success and predictability, over fallback
recovery leading to potentially/eventually undesirable outcomes).


> I believe this balance could be revisited in several years' time, if "HTTPS
> Record" support becomes sufficiently universal.

Indeed it is a possible position to say that the Internet is not yet
ready for semantically distinct services seen by SVCB-aware and legacy
clients.  But I think that latching on success of the initial lookup
largely addresses the present impediments to reliance on SVCB.

> Viktor notes with concern that AliasMode is a "non-deterministic
> redirect".  Instead, the draft attempts to model the client behavior as a
> preference ordered stack of endpoints:
> 

I also noted an issue around the initial $QNAME having prefix labels (in
the case of SVCB rather than HTTPS), and so this is likely not the name
you want appended as a fallback to the target list.

Similarly, if an AliasMode target has attrleaf labels, RFC1123 seems to
preclude publishing A/AAAA records there, making some of the example
configurations in the draft impractical.

-- 
    Viktor.