Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Tommy Pauly <> Wed, 19 May 2021 21:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FECF3A206C for <>; Wed, 19 May 2021 14:51:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.794
X-Spam-Status: No, score=-7.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yD3eFbpOR_dP for <>; Wed, 19 May 2021 14:51:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE5BA3A206D for <>; Wed, 19 May 2021 14:51:27 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 14JLhsp2012134; Wed, 19 May 2021 14:51:23 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=content-type : content-transfer-encoding : from : mime-version : subject : date : message-id : references : cc : in-reply-to : to; s=20180706; bh=bfxuQhtYccwsjkruTcXiWixWkcoK9JuqonYOXRSwj88=; b=ZdahG6aZIGpQ92o/s/KSuNZdBhP8pq7FSHFFE2OVvls5TnJ66fQ/ynR6h6uLR/VWReNU 6sd2S59R4rgCi/O5o6uG0B7x52b5UDpTSB8mFFtzW1Jyx7pFc6bB9TOXR3+yK4UoOD9z xkDHWuSEHq8/vH/yrMQhdAIBDLClh8St5S+mo70tbOisJlrYOg4QLtS+Ne5tXKhqk5Wu q3zWjeU5GWinVFneJDR4r6t9hhdDO6ePYDQ38QCTvgBCfskcaD00Pc33hyQq7kJG6/pT h9QsPmx1tx1y+Ud6WmDbm77DGzPQEm6G8afgAMdz8GtDYX+V+u5YTcDoqx4JpQsSc+EO Ew==
Received: from ( []) by with ESMTP id 38jayt352q-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 19 May 2021 14:51:23 -0700
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Dec 3 2020)) with ESMTPS id <>; Wed, 19 May 2021 14:51:22 -0700 (PDT)
Received: from by (Oracle Communications Messaging Server 64bit (built Dec 3 2020)) id <>; Wed, 19 May 2021 14:51:22 -0700 (PDT)
X-Va-T-CD: cf81a03552d72e88b2c7c1a9075a2c16
X-Va-E-CD: 15cf04f9eac2eb842091974d83fbd438
X-Va-R-CD: d937fe06e0025caedf842e3d09b5492f
X-Va-CD: 0
X-Va-ID: fb1a756f-f87f-41de-b11d-58b5d91f57ca
X-V-T-CD: cf81a03552d72e88b2c7c1a9075a2c16
X-V-E-CD: 15cf04f9eac2eb842091974d83fbd438
X-V-R-CD: d937fe06e0025caedf842e3d09b5492f
X-V-CD: 0
X-V-ID: 8228d16c-a09b-464d-9705-439b24b4f50a
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-19_10:2021-05-19, 2021-05-19 signatures=0
Received: from (unknown []) by (Oracle Communications Messaging Server 64bit (built Dec 3 2020)) with ESMTPSA id <>; Wed, 19 May 2021 14:51:22 -0700 (PDT)
Content-type: multipart/alternative; boundary=Apple-Mail-7EB43372-CFCD-49CB-985E-E64659C4494B
Content-transfer-encoding: 7bit
From: Tommy Pauly <>
MIME-version: 1.0 (1.0)
Date: Wed, 19 May 2021 14:51:21 -0700
Message-id: <>
References: <>
Cc: Brian Dickson <>, dnsop <>, Ben Schwartz <>, John Levine <>, Eric Orth <>, Joe Abley <>
In-reply-to: <>
To: Erik Nygren <>
X-Mailer: iPhone Mail (19A5261d)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-19_10:2021-05-19, 2021-05-19 signatures=0
Archived-At: <>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 May 2021 21:51:32 -0000

> On May 19, 2021, at 2:37 PM, Erik Nygren <> wrote:
>> On Wed, May 19, 2021 at 5:12 PM Tommy Pauly <> wrote:
>>> On May 19, 2021, at 1:34 PM, Brian Dickson <> wrote:
>>> On Wed, May 19, 2021 at 7:49 AM Tommy Pauly <> wrote:
>>>> I wanted to chime in on this discussion as a client-side implementor who has already widely deployed support for SVCB/HTTPS.
>>>> The current format, where the parameters are structured as a list within a single RR, is certainly simpler and less error prone for processing. Much of the information contained as parameters within the SVCB RR are useful for higher-level “application” logic. Within our deployment, the DNS stub resolver daemon receives the RR and does the parsing, and passes up the parameters bundle as a blob that is more or less opaque, to the layer that handles actual connection processing (doing happy eyeballs, protocol selection).
>>>> Processing the content of SVCB parameters must be handled atomically: the ALPN, ECH config, and any other information must be handled clearly as a unit and not have any chance of being broken up. Lots of code is already based on processing RRs as chunks of data, and requiring anyone looking at the information to stitch the parameter list back together based on multiple RRs that must be in a particular order adds complexity and invites in bugs and errors.
>>>> I’d strongly encourage sticking with the wire image we’ve already been using and deploying.
>>> Would it be accurate to say that as long as the wire format of both SVCB and HTTPS do not change, your client implementation(s) would not be impacted by any changes to zone file format?
>>> I.e. you don't implement any server code, so what the zone format is does not affect you, and how the wire format gets produced from the zone format is not relevant to you?
>> That’s correct. My main concern here is keeping the wire format consistent and simple. How the zone format file works is indeed something separate, and not something I have strong opinions on. Anything we can do to make the processing simple for both sides is great.
> Also as I understand it, changes that substantially change the semantics of the records but preserving
> the presentation format and wire format would also affect you?  In particular, any shift from
> a RR-per-service-binding to having service bindings span RRs in the RRset would add significant
> complexity to your client implementation as you've described?

Correct. I’m saying that the wire format should remain as defined, as well as the contents and semantics—the single RR containing the various parameters needed to interpret a single service instance, with ALPN/ECH/Hints all together. Changing the way this service is spelled, such as breaking it into separate RRs, effectively breaks the wire format (since it is no longer intelligible as a single service). 
> Separately I've opened
> to explore if there are ways we can simplify through character set constraints.
> In-particular, if we could get ALPN constrained to a set of token characters
> (and similarly constrain future SvcParams that want to be value lists to use 
> a limited subset of characters)  then some of the parsing concerns get simpler.
> I've mailed the TLS WG as they may not be willing to change how ALPN registry
> entries are handled in which case we'd still need a solution here.
> Best, Erik