IETF Logo Mail Archive

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

Tommy Pauly <tpauly@apple.com> Fri, 10 July 2020 01:41 UTC

Return-Path: <tpauly@apple.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 3E5AE3A0B3B; Thu, 9 Jul 2020 18:41:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 wfE0ivnSvDhJ; Thu, 9 Jul 2020 18:41:46 -0700 (PDT)
Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (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 A1C703A0B2E; Thu, 9 Jul 2020 18:41:46 -0700 (PDT)
Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 06A1W9rv023460; Thu, 9 Jul 2020 18:41:45 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=PpRzvWe+eMBBo0M5LvAvh/LnggQuuFfu5htAuoHTHW8=; b=OqrlkircamwJEQMpOwTxLG1AuZtD98D5xjZa2y8DI08bEw0P6hFJfbJAC8nLw1+O3YpM l0pSXCjpLlSITTf7n09l2+YPbuBmyRk6w5QQMAlSU2kw0rAtNtPoOtMLZxnL2Frbzng8 dLFYb58QzNmvEyHWSOclvp7TFj6DlIPLhq9hDmVk0Bq1rcyW6w8EAvKI1xpG7lKAQbLS z1ai5WkWaejnmta5gzDwgVJ6RYnXUpjM1RD5BOYxK9nhMwu7VdJPWAeouaKSVj7DaRoa Ek0THwAO4yPYuctGzohRFx0vUC5RsHJi+R4mYK3j+X869895ZzGO7IxPGDID4Ir7iewt Qw==
Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by nwk-aaemail-lapp03.apple.com with ESMTP id 326bbaux38-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 09 Jul 2020 18:41:45 -0700
Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QD8008O6CPLIHG0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Thu, 09 Jul 2020 18:41:45 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QD800U00CLD0600@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Thu, 09 Jul 2020 18:41:45 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 2ce39ff0c0ed9d51382b7e8c781d4e54
X-Va-E-CD: 069fcc17872cc9dd0518830ffb5e2b24
X-Va-R-CD: 8ec2a988c10103ea0fc31fe6ae4217d7
X-Va-CD: 0
X-Va-ID: 8c766c39-a8a5-4ffb-9be9-0e98eca303ac
X-V-A:
X-V-T-CD: 2ce39ff0c0ed9d51382b7e8c781d4e54
X-V-E-CD: 069fcc17872cc9dd0518830ffb5e2b24
X-V-R-CD: 8ec2a988c10103ea0fc31fe6ae4217d7
X-V-CD: 0
X-V-ID: da5ebff5-0402-4f0f-a6c0-12f623f80af2
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-09_11:2020-07-09, 2020-07-09 signatures=0
Received: from [17.232.179.115] (unknown [17.232.179.115]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QD800Z11CPKPQ00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Thu, 09 Jul 2020 18:41:45 -0700 (PDT)
From: Tommy Pauly <tpauly@apple.com>
Message-id: <F628F5DB-BF67-4EDF-A078-FEAD53733A70@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_E04A3711-871A-4F58-97F2-94BB93A24A5E"
MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\))
Date: Thu, 09 Jul 2020 18:41:43 -0700
In-reply-to: <CAHbrMsCwGjg9zaQXmWrsnQzrJq_2jtcx3CudCGazzMKXyefjLQ@mail.gmail.com>
Cc: Mark Andrews <marka@isc.org>, dnsop WG <dnsop@ietf.org>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
References: <F63A6D01-56C9-439A-A4B8-4855AC7F7E93@isc.org> <CAHbrMsCwGjg9zaQXmWrsnQzrJq_2jtcx3CudCGazzMKXyefjLQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.7.2.3)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-09_11:2020-07-09, 2020-07-09 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9M6NzpPX1Lzz7LMI84phSUhH53A>
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 01:41:48 -0000


> On Jul 9, 2020, at 5:27 PM, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org> wrote:
> 
> 
> 
> On Thu, Jul 9, 2020, 8:04 PM Mark Andrews <marka@isc.org <mailto: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.
> 
> 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.

Yes, this seems like the simplest way to track this from the server standpoint. That does require having a server listening on another port/address, but presumably if you’re getting benefit from SVCB, you probably have something you’re pointing to.

We can imagine a world once most clients are HTTPS/SVCB-aware that the A and AAAA records stop being used for load balancing, but just point to the “fallback” configuration, and servers can detect support for HTTPS/SVCB in client by detecting the use of those services. 

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

v2.23.0 | Report a Bug | By Email