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

Erik Nygren <> Wed, 19 May 2021 21:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5AA543A1FF4 for <>; Wed, 19 May 2021 14:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zxjNIr-VtnIk for <>; Wed, 19 May 2021 14:36:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 472E43A1FF2 for <>; Wed, 19 May 2021 14:36:37 -0700 (PDT)
Received: by with SMTP id f6-20020a1c1f060000b0290175ca89f698so4192040wmf.5 for <>; Wed, 19 May 2021 14:36:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RySORjwh7Dt8IWRYV7ocQAVfBdN5CUL/R4CBbuAsKm8=; b=pn7YW6YuwCyJQA07AKE3bZGmJbYAWi1YAWpyFHAxrID4QkgRefEIzTwcMuTCtyzoK4 +iNoE/nzp7NW/DnUf2mcgxGDOaMlJazyIW/MttHQDS4kMtaRxDi2ciT8ilM+0+fsh/d5 twGQ9xjj0CYa+kczVMpTcI+q07R0PUIbznR2/pgIZ7T0TEsKj8L+VuRbgNLa8oED/kgO zhqDSd8Wy2z/2XlpXwzdh+8IFCEn+s2wWRHgXqkLu73d9RYx0WRrSuPup38s++n3j48w 1HG7KLPg5Tu9RwgiEz975yDIQ9duYXghegKso0Oya74ScbrFOmM82I6mYQfTplx2hjET 1ueg==
X-Gm-Message-State: AOAM532NnEfa7f6LFuh5PfGjSQWKC/2YSEw8/XpKORjDxk8Z4HcypM6J 7gHnPb7JJqnta6CPn31k8UBgsz2ybVOsr/Bxz8w=
X-Google-Smtp-Source: ABdhPJy677jSC+fX5JhimTEo7y2OXW3CQ9ZrRLlC/Ty5Qrj7gX0oc8IpKY9FsmpMViljShx2GCjBM26wmHR/l57iJWE=
X-Received: by 2002:a05:600c:4f8b:: with SMTP id n11mr655836wmq.11.1621460195524; Wed, 19 May 2021 14:36:35 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210512213903.D5F1F7AA827@ary.qy> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Erik Nygren <>
Date: Wed, 19 May 2021 17:36:24 -0400
Message-ID: <>
To: Tommy Pauly <>
Cc: Brian Dickson <>, dnsop <>, Ben Schwartz <>, John Levine <>, Eric Orth <>, Joe Abley <>
Content-Type: multipart/alternative; boundary="000000000000f8c7d305c2b59e73"
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:36:42 -0000

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?

Separately I've opened
to explore if there are ways we can simplify through character set
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
a limited subset of characters)  then some of the parsing concerns get
I've mailed the TLS WG as they may not be willing to change how ALPN
entries are handled in which case we'd still need a solution here.

Best, Erik