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

Brian Dickson <> Tue, 18 May 2021 06:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 433403A11D5 for <>; Mon, 17 May 2021 23:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 qPXe-X83y8Pw for <>; Mon, 17 May 2021 23:00:50 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D93F43A11D3 for <>; Mon, 17 May 2021 23:00:49 -0700 (PDT)
Received: by with SMTP id i22so12231100lfl.10 for <>; Mon, 17 May 2021 23:00:49 -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=fd8Jf3LjYYifhcvHVagvP30W4PA1HdND9C4F/aI/vTo=; b=eXrHlLn2XCOifYiniy0irDzHaXFtFQrw68/9x5faJd9AEWjN+4HPFjimYKuBda4SxM DxZ+tuWZPpeASf/K+XyvjcQ3cuSHGIOO0oPsK7FpKBD31mfQFGmfCLSAm8KawUE29Yl5 o4C+50LykT4jwTrpRCBj6qKBDpAPnPT1HEvD/tUe+8gZUQXjSxHVUV6Du4QoTvdn4tmh EZANlW0wF1YozVBF9SWzdoXhkyGmVMF2kWM2JDPW3goKOkzm8JJ2kHjmSkcGBRPhf+V/ JkmY23Z4ujWDn54FKIqFttXbD4ST0Jf7i2uXT9NqDe1pDVe3rQ6QqeinFkZh5GYT5m2U 7PoA==
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=fd8Jf3LjYYifhcvHVagvP30W4PA1HdND9C4F/aI/vTo=; b=N0pdtiZCpPfEeHRpFee8jsF08lz8SJ5Gcb4msNOq4ajlgnOkb58qZWtcMOP6mkU1Ub 03oilPnD1EBFG404XeDHk+2Io35pJV/wRT0aWGrykVe7gVTYlPsadyyO2Ocz7HfJGs3s +/vUfekiGkkffsl0Cm6NIIsYgPn/aLpPO2Rq5u3v89MdLp1cacwllVik+3dVc4037+bz J/IrCY8yeimkVk9KizPYxG1zt7i12/BTrP54IsDSaiXYjK2Bb4D56//7Z6p8dKke1v0A 6e+cIyGIqrSnBnckiSDgUnAUxhs3SUxnx1olUsCwRO4Vk0ATSn+rtuid6GN6vzlh3PAB KVQg==
X-Gm-Message-State: AOAM5302wPIzpTYTHT2swZjwslCR7ZnP/MEYuPAEDtyHXPp9P0iwVsM3 OMVK0O90glsZKB4/QAijxkFtLkxiZf8fJMmyHh8=
X-Google-Smtp-Source: ABdhPJytewDYC4uPcn2ch1n5gdBtoabKsfbY5Eawys+F3+gU9a45oNrCXZgDwT0K2AdfnprDPZB4k0PWeLKv74Ab79M=
X-Received: by 2002:a05:6512:118c:: with SMTP id g12mr2963474lfr.316.1621317647289; Mon, 17 May 2021 23:00:47 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210512213903.D5F1F7AA827@ary.qy> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Mon, 17 May 2021 23:00:35 -0700
Message-ID: <>
To: Ben Schwartz <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="0000000000006f519105c2946e8e"
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 06:00:55 -0000

On Mon, May 17, 2021 at 3:48 PM Ben Schwartz <> wrote:

> On Mon, May 17, 2021 at 2:46 PM Brian Dickson <
>> wrote:
>> I re-read (several times) the current -05 version of the draft. I found
>> it difficult to follow and understand several aspects of the "automatically
>> mandatory", "mandatory", and mandatory usage in the document, both
>> syntactically and semantically.
> I'm sorry this wasn't clear.  The text at the top of Section 7 defines the
> terminology
>    In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the
>    RR will not function correctly for clients that ignore this
>    SvcParamKey.  Each SVCB protocol mapping SHOULD specify a set of keys
>    that are "automatically mandatory", i.e. mandatory if they are
>    present in an RR.
> ...
>> 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 ... interesting. The terminology and tables should probably try to
make that more obvious.

> 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.

Also kind of interesting. The purpose of IANA is to publish useful
information related to standards, at least that's my take on it.
Those tables ARE THEMSELVES IETF-controlled via whatever rules apply. IANA
does not do anything unilaterally.
(Examples would include things like 'RFC required', or 'Expert review', or
'Standards Action', at least in the DNS tables.)

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?

> an additional table column specific to that registry should be
>> included/added: "non-negotiable", i.e. MTI for this binding.
> A "service binding" is a single SVCB RR; I presume you mean the "mapping",
> a document that defines how to use SVCB in some context.

Yes, I meant mapping, as in the protocol definition for an RR type that
implements any SVCB protocol-specific record, including what defaults are,
what SvcParams are in-scope (and possibly newly defined), etc.

> It sounds like "non-negotiable" is a synonym for "automatically
> mandatory".  I'm certainly open to changing the draft's terminology.
> "non-negotiable" might be clearer, although I'm not sure what negotiation
> it's describing.
>>    - Replace the "mandatory" thing, with an "optional" flag to be
>>    optionally appended to any parameters that are not "non-negotiable".
>>       - This also removes the need to have a sorted list of mandatory
>>       attributes
>>       - Each binding will have a list of non-negotiable attributes,
>>       which can be used for validating the "optional" flag on both the authority
>>       side and the client.
>>       - Any parameter that is not non-negotiable, but does not have the
>>       optional flag, must be supported by the client for the parent HTTPS/SVCB
>>       record to be accepted by the client.
>> It sounds like this "optional" flag is exactly the inverse of the present
> "mandatory" indication.  The present structure was chosen in part to
> simplify the zone file and wire formats, by avoiding an additional mark
> that must be written or parsed on every SvcParam.

Yes, the reverse of mandatory.
The "optional" flag would only be required if the particular SvcParam was
not in the corresponding "mandatory" list.
It would not be needed for things that are mandatory, so not always
And not ever present for anything that is "automatically mandatory".
In the case of HTTPS, the only params that MIGHT have the optional flag
would be ip4hint, ip6hint, and ecn.
(The other types would not be eligible for the optional flag. This is the
intended meaning of "non-negotiable", as in, they can never have the
"optional" flag applied to them.)

> Additionally, for compatibility, it seems likely that the great majority
> of parameters will either be automatically mandatory (as specified in the
> mapping document) or optional (especially if they are introduced later), so
> making parameters mandatory unless marked otherwise seems like the wrong
> default.
>>    - The binding tables then become lists of parameter sub-types that
>>    the specific binding uses, marked as optional-allowed or non-negotiable.
>>    The binding table incorporates all the MTI sub-types as well.
>> I'm not sure what you're describing, but note that new parameters can be
> defined over time, and we do not want every new parameter draft to Update
> the SVCB RFC.  The proposed parameter registration policy is
> first-come-first-served, with the understanding that clients will normally
> ignore new parameters that they do not recognize.

That is consistent with my understanding. However, I would note that having
an IANA registry means not having to update any previous drafts. The IANA
tables can have columns that list appropriate sets of RFCs that make use of
a parameter, for example.

The main IANA table for DNS RRtypes is an example of such a table. It gets
updated by new RFCs (or sometimes IDs with early allocation).

There are a number of other tables for DNS, such as algorithms, EDNS
versions, flags, etc., Extended DNS Error Codes, etc.

>>    - The binding tables obviously still need default values (if
>>    appropriate), e.g. for ALPN.
>> The HTTPS binding would then consist of:
>>    - Default ALPN of "http/1.1"
>>    - MTI of "alpn"
>> Note that declaring alpn to be "MTI" would have no effect.  As presently
> defined for HTTPS, the "alpn" SvcParamKey only adds advertised protocols.
> If you prefer to stick to the default protocol (TLS over TCP), you can
> "implement" the alpn parameter by ignoring it.

So, no-default-alpn is automatically mandatory, but alpn is not? Unless
alpn is included in the mandatory list.
So, an HTTPS record could have "no-default-alpn" and "alpn", and the client
would not need to implement alpn, but at that point would have an alpn set
that is empty.
I'm not sure that's important...

>>    - aNN of "port"
>>    - NN of "no-default-alpn"
>>    - Optional of "ecn"
>>    - Optional of "ip4hint"
>>    - Optional of "ip6hint"
>> And an HTTPS referenced record (included by reference from record with
>> SvcPriority between 1 and 127), would have the following rules:
>>    - Any "optional" parameter MUST be implemented by the client, UNLESS
>>    the "optional" flag is present in the HTTPS referenced record
>> 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
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
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

Suppose a client supports only a subset of the defined params.
The client can discard any params records with types it does not support.
If any of those params records are not optional, the "parent" record would
then be discarded as well.

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.
(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

I did a quick test implementation, and the wire overhead was not a
substantial increase, about 40%.
The simplicity on the zone file parsing is a useful benefit, as is the
ability to independently filter/flag parameters on the client side.
This will likely be more of a concern as more mappings get defined, IMHO.