IETF Logo Mail Archive

Re: [DNSOP] HTTPS and SVBC client support measurement.

Mark Andrews <marka@isc.org> Fri, 10 July 2020 00:51 UTC

Return-Path: <marka@isc.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 9A49D3A0A93 for <dnsop@ietfa.amsl.com>; Thu, 9 Jul 2020 17:51:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 pL_fMxUIfSKA for <dnsop@ietfa.amsl.com>; Thu, 9 Jul 2020 17:51:20 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 41BB13A0A85 for <dnsop@ietf.org>; Thu, 9 Jul 2020 17:51:20 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 26ADE3AB002; Fri, 10 Jul 2020 00:51:20 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 1CB4416003E; Fri, 10 Jul 2020 00:51:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0D71816007D; Fri, 10 Jul 2020 00:51:20 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0GKN3LmbCGKm; Fri, 10 Jul 2020 00:51:19 +0000 (UTC)
Received: from [1.0.0.3] (unknown [49.2.181.130]) by zmx1.isc.org (Postfix) with ESMTPSA id 64CF316003E; Fri, 10 Jul 2020 00:51:19 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <CAHbrMsCwGjg9zaQXmWrsnQzrJq_2jtcx3CudCGazzMKXyefjLQ@mail.gmail.com>
Date: Fri, 10 Jul 2020 10:51:16 +1000
Cc: dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <242DC956-0B1A-48A2-9CCB-25B2A12625E7@isc.org>
References: <F63A6D01-56C9-439A-A4B8-4855AC7F7E93@isc.org> <CAHbrMsCwGjg9zaQXmWrsnQzrJq_2jtcx3CudCGazzMKXyefjLQ@mail.gmail.com>
To: Ben Schwartz <bemasc@google.com>
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hpEdz0NTKMuOf3G5JpwqMgpoCZE>
Subject: Re: [DNSOP] HTTPS and SVBC client support measurement.
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: Fri, 10 Jul 2020 00:51:22 -0000


> On 10 Jul 2020, at 10:27, Ben Schwartz <bemasc@google.com> wrote:
> 
> 
> 
> On Thu, Jul 9, 2020, 8:04 PM Mark Andrews <marka@isc.org> wrote:
> It would be useful if there was a way to measure client support for HTTPS and SVBC even when they are not in use.  Perhaps a HTTP header could be added to signal that the client supports HTTPS? This will provide server administrators information about their client population to decide when it is safe to remove support for legacy clients.
> 
> I don't foresee anyone removing support for non-SVCB-aware clients (I wouldn't call them "legacy") any time soon.  That sounds like a change that would take many decades, if it even proves desirable.

Well it proved desirable for SMTP. A records used to exist at zone apexes simply to support email to that name for many years after MX support was effectively universal simply because it was next to impossible to measure client support for MX.

Having a A or AAAA pointing at a third party introduces risks of other protocols being processed by the third party beyond those that party is supposed to accept.  Even when it isn’t a third party the servers often need to know the name used to connect to them to make sensible decisions about how to respond. Reducing the number A and AAAA records with different names helps here.

> However, I think your purpose here is already well-served by the current draft.  If you publish SVCB records that point to a different server IP address or port from the non-SVCB connections, you can easily observe what fraction of users are SVCB-enabled.

but those mechanisms don’t help people deciding whether to publish HTTPS/SVBC in the first place.

> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org

v2.23.0 | Report a Bug | By Email