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

Ben Schwartz <> Tue, 18 May 2021 20:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E73653A0CB8 for <>; Tue, 18 May 2021 13:56:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 03ro6roQpn-u for <>; Tue, 18 May 2021 13:56:21 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 37CD23A0CB7 for <>; Tue, 18 May 2021 13:56:21 -0700 (PDT)
Received: by with SMTP id j14so9953129wrq.5 for <>; Tue, 18 May 2021 13:56:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+BzwQ5GVsZFHNxwoketw3Zc/85Ij6/2y0jk7+h5mzEc=; b=U1bSjVWwKvH62NmrYH28Dms2XudLWyxei9LFHmZKnl5PQ8mU/4EY9aFfGk3ZZ2nuJ9 KibkdntvDS2T4gzkuyycgIfcOqA/Zi0FdxNb0JsWrxtVD4ZawxcUnzJUzuBzM1c8TS2/ 40x5uIc5Eg/8hIqns69vC3dsRbp1yywmI5vY/scjisYsDxH+eTZNbPEYToPRE9vOOoB2 mzyW9PnJAZBCBnuaYCuQysRMzZi61L+B5RnB28nlF/A7w5uy73JScT/HifGQZqyjsJCC yWbDl3pa1jVpKjKQlKRIVV4nStPvxAvmSnA9TQZ0/2xR6/Q1JbAu7KYWNKHufBvzEpS0 pIRQ==
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=+BzwQ5GVsZFHNxwoketw3Zc/85Ij6/2y0jk7+h5mzEc=; b=DR5kfQqNkWWoX/nGkUwt4idXhi+QEnH/YJBQAIw06k0DuZyYtYMqo8uXdGX6Wl9ZBB b0KYw2xpnPYlt7zg4g2BFROqZ/mJevnRPUeYE9OMEdNKzi2wkx1yx0Ae1Ht1yi8JvVs3 t2SZE3U0whxb9ihlfia9wyAz9OBcoyaQ7aNxyrzH/YaqNUCBMeJ1JcmyrSKx/2bvAAmf 7HSVIbF4dUWd/+YsN8iUCQWQn9+fe06dFregSU5U10bCbWNx0bpoYM46t4gSQed7tVI7 XN2ufH12N2QV7QYExKQ+7Ls49nAVk9wRdvJIL0zqMq/wDaNQRfUeSAdZX7WdI60dbNJ3 f8Ag==
X-Gm-Message-State: AOAM533frwLOqCwYXDeWaw0+9+y0ZP2Ar2D0Wek3vvgkmM+Ob9a6B4jQ GaT1esvULO7mG6sSzvJJureuF+D/UGt1+Vs832j3Bw==
X-Google-Smtp-Source: ABdhPJyoA4ZDcKvla7Oq2l8CubpPvWLxc8HTarT87XX3LpFGQcZMndnxgU10z94f7lHkSbwkMI1LqbtQMhKOnW9hwVI=
X-Received: by 2002:a5d:44cb:: with SMTP id z11mr9586256wrr.159.1621371377444; Tue, 18 May 2021 13:56:17 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210512213903.D5F1F7AA827@ary.qy> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Tue, 18 May 2021 13:56:05 -0700
Message-ID: <>
To: Brian Dickson <>
Cc: dnsop <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000069f4a05c2a0f11b"
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: Tue, 18 May 2021 20:56:24 -0000

On Mon, May 17, 2021 at 11:00 PM Brian Dickson <> wrote:

> On Mon, May 17, 2021 at 3:48 PM Ben Schwartz <> wrote:
>> On Mon, May 17, 2021 at 2:46 PM Brian Dickson <
>>> wrote:
> ...

> Here are some specific suggestions, including incorporating the updated
>>> proposed encodings:
>>>    - Use the term MTI (mandatory to implement)
>>>       - MTI parameters would be "alpn", (maybe) "no-default-alpn", and
>>>       (maybe) "port"
>>>       - The IANA table in 14.3.2 really needs an MTI column in addition
>>>       to the other columns
>>> In the HTTPS protocol mapping as presently defined, there are no MTI
>> parameters.  A compliant client implementation might not have any supported
>> parameters.  We could add a row for this in the table, but its value would
>> be "none".  (Future mappings may indeed have MTI parameters.)
> Okay, so if I understand this correctly, a compliant client would NOT need
> to understand "alpn" as an SvcParameter for HTTPS?
> But it would need to understand the "default" ALPN of "http/1.1"?

That's essentially correct.  A client that only supports the default ALPN
has no use for the "alpn" SvcParam.

That's ... interesting. The terminology and tables should probably try to
> make that more obvious.

Perhaps you can suggest a clarification?  We should definitely make the
terminology as clear as possible.

As the table notes, the "automatically mandatory" parameters are
>> "no-default-alpn" and "port".  A client that doesn't support any parameters
>> would ignore any record that contains these parameters.
>>>    - For each binding registry,
>>> Mapping documents are IETF-controlled, not IANA-controlled, so there
>> isn't a "registry" per se.
> ...

> I don't understand why you are making that distinction? Or why IANA table
> updates via new RFCs (without necessarily altering either existing table
> entries or prior RFCs) aren't compatible with that intent?

My point is that SVCB mappings are IETF documents, complete with guidance,
normative language, deviations, exceptions, etc.  The summary table in
Appendix B is non-normative, and not connected to IANA in any way.  There
is no registry of mappings.


> > It seems you are drawing distinctions between "mandatory to implement",
> "non-negotiable", "optional", and "flagged optional".  I don't believe this
> is a simpler formulation than the current draft.  By working through an
> alternative formulation, I think you've shown that the complexity is
> irreducible.

> Flagged-optional is in an RR; optional is in (what I was supposing or
> proposing to be) an IANA table indicating which types are permitted to be
> flagged as optional, for any particular mapping.
> The distinction between MTI and NN, is only relevant if there are any
> MTIs. If there are no MTIs, then each parameter is either NN or optional.
> It might help, at least for purposes of clarity and for the use case of
> the mapping for HTTPS, to put all of the "always mandatory" elements as the
> lowest-numbered values (i.e. 0 and 1).
> It might be the case that new mappings don't consider those
> always-mandatory.

Right; if we bake optional/mandatory-ness into the key itself, then not
only do we complicate the format; we also constrain future designs in ways
that are hard to foresee.

Given that you are reserving a 16-bit range of values, it might be helpful
> to group them into "always mandatory for some mappings". Except that which
> ones are, might differ on new mappings.
> Maybe put more structure into the 16-bit field, with e.g. a bit for
> "always mandatory".

It's certainly possible to imagine a format where we steal bits from the
TLV type field as flags for optional/mandatory.  The current approach was
chosen because it preserves the simple OPT-style TLV wire format, and
allows the mandatory/optional concepts to be separated entirely from the
wire-format and zone-file-format processing.

If a new mapping would otherwise have re-used a param, using a new param
> with different "always mandatory" bit value might make it clearer across
> those mappings (and allow mappings to check bits rather than going through
> all the parameters.)
>> I continue to prefer the current draft, as it provides the correct
>> behavior in ordinary cases with simple inputs like
>> 1 . alpn="h2,h3" ech=...
> There are some client efficiencies that aren't obvious, I don't think.
> Here is the same pair of records, using the two different encoding schemes:
> ;; pool HTTPS 1 h3pool alpn=h2,h3 ech="123..."
> ;; pool HTTPS 2 .      alpn=h2 ech="abc..."
> ;; pool TYPE66 1 h3pool 32768
> ;; pool TYPE66 2 . 32769
> ;; pool TYPE66 32768 alpn "h2"
> ;; pool TYPE66 32768 alpn "h3"
> ;; pool TYPE66 32768 ecn "123..." optional
> ;; pool TYPE66 32769 alpn "h2"
> ;; pool TYPE66 32769 ecn "abc..." optional

I find the second format much more difficult to read.  The relevant
information for each binding is spread across multiple lines in potentially
arbitrary order, bound together by identifiers that the reader must
remember.  It also seems like it would be much more work to write, and more

Suppose a client supports only a subset of the defined params.
> The client can discard any params records with types it does not support.

I'm not sure what you're implying.  A client processing step that discards
some entries from the SvcParams map can do so regardless of what wire
format is in use.

> If any of those params records are not optional, the "parent" record would
> then be discarded as well.

Currently, this is covered under the definition of "compatible record" in
Section 7, and referenced in the description of client behavior: "A
ServiceMode RR is considered "compatible" with a client if the client
recognizes all the mandatory keys, and their values indicate that
successful connection establishment is possible.".

I don't think spreading the binding across multiple records makes this
easier to understand or implement.

Note that this representation actually breaks the ALPN into one record for
> each list element, so there is no need for any escaping. Each list element
> can be treated as a string, with or without any commas.

Yes.  However, note that this does not remove the need for nested escaping
in general.

This syntax makes every value into a set, even for keys that can only have
a single logical value, requiring additional validation to ensure that
single-valued keys stay single-valued.  It makes the "optional" flag an
independent property of each element of the set, creating the potential for
considerable complexity in handling differing optionality within a

It also creates significant complexity for any future value that takes the
form of an ordered list.

(This may help implementations on the intersection stuff between things the
> client supports and what the ALPN offers, but I'm not sure if that's the
> case and/or important.)
> I'm hoping this feedback is useful, with or without the specific encoding
> scheme.
> I did a quick test implementation, and the wire overhead was not a
> substantial increase, about 40%.

This seems like a considerable increase for a high-traffic record type.