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

Brian Dickson <> Fri, 21 May 2021 18:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C7AA3A1A2D for <>; Fri, 21 May 2021 11:16:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Pb24i-j2cueY for <>; Fri, 21 May 2021 11:16:26 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3599E3A1A54 for <>; Fri, 21 May 2021 11:16:26 -0700 (PDT)
Received: by with SMTP id c15so24988265ljr.7 for <>; Fri, 21 May 2021 11:16:25 -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=D77i/QI0EWeLx0SIj4H3RJpSM8cnMFrOdto34CCH/pY=; b=eYAKSMJ+yQwRHo8T8Teq7Nc8RIxkICjsg/xUofY21pE7Wwd6iX+a7qN2wG3eAoAJzM K8tXSVT6b1bLpAhD29RY1w5Iv9ramW1QtjzAHGlvCO5HV8FEuHxpT3GjHU6w9Hth/ueu nx5ZbrJjiMY7Xeu5cyRQb2VkY0B13vwP+xUFO6neRYiLAk7vjQh+wIM6ldQOudupDyxF JhsBimE216FREb07cVZ2GKk7WBNNI3kdYLRGF06E2euxB8JQhLnHUM8i9vik/+6IRs4v xU3Hk8ADOxGA6Jdgic587XkpZTRqmmFP8He/kD9jyNFytj2cOIc8XcNmlZcE7XHHzTgQ njrg==
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=D77i/QI0EWeLx0SIj4H3RJpSM8cnMFrOdto34CCH/pY=; b=Miv58APsbUsgulbRahzAc2loB+DjMBrw2Gyuq8dbhRoSAK3q/jfpwHC1dolQpb4O4f kMT4XIBp59eMcWc47uA/VI6588XV95DQNLaqXMrz7zQEtSRPMONgSWp3vxk5FZnukumY ZCWnTgMovljoAo/pHRDd9g8UzW/xEUdSpMXqEezSIkiP8X7CLnGUzdOx5YPsyQN+MM8y Kcg/CP8yy7hxHhbe0TCv5nua9KOE8MqT1LCVMq4lLCzX5peyrpoYgPyKd02NFHJAQnum dRxEJO/1Be3trK5menjr3xh1Dd4Ra9rSD/nuovoBfv/3AOyqw76iPWc5zTY68jisizPg MajA==
X-Gm-Message-State: AOAM5308oOcSLrMQbaWdlUEZrt37yh6Y8rlYm1OF0+PeFYO5QCrPgtiF TfYNtTSM+68O1q4ad/lGuBQ9lV2zp1zsJpO/M15Q8ZxMseI=
X-Google-Smtp-Source: ABdhPJxuhUujdO8iH9AEhPyuN2pO+88DF9me7E+g5ky18Tr1ZMZKqRurtrWGi9g3d0T6vVY1jR0rV9tKt9XwyBg8EyY=
X-Received: by 2002:a2e:8746:: with SMTP id q6mr7718174ljj.416.1621620983610; Fri, 21 May 2021 11:16:23 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210512213903.D5F1F7AA827@ary.qy> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Fri, 21 May 2021 11:16:11 -0700
Message-ID: <>
To: Ralf Weber <>
Cc: Eric Orth <>, WG <>, Martin Thomson <>
Content-Type: multipart/alternative; boundary="000000000000b041bf05c2db0e36"
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: Fri, 21 May 2021 18:16:31 -0000

On Thu, May 20, 2021 at 11:29 AM Ralf Weber <> wrote:

> Moin!
> On 20 May 2021, at 19:59, Eric Orth wrote:
> > A big selling point behind why we have client implementers planning to
> > query HTTPS records is the expectation that this will be the only query
> > type we will need to add and that it can be extended to handle any future
> > information we need for establishing HTTPS connections (and we want
> > mechanisms to be able to add stuff in the future to keep improving HTTPS
> > connection behavior).  It is not practical to add too many additional DNS
> > queries to make web requests, and nobody wants a
> > deprecation/new-SVCB-based-record-type cycle every time we need to add
> > something.  So in the end, I do not expect HTTPS would see much adoption
> > without the extensibility.
> I fully agree. The point I was making is that ECH sort of already is an
> extension that were not in the original draft and there may be other
> Enhancements in the future.

I think the handling of presentation formats and wire formats leaves much
to be desired.

However, the handling of future extensions is not (IMHO) currently usable
via the existing proposed mechanism.

The discussion about "what if ECN needed to be added later" got me thinking
about the issue.

I think there is a need for something similar to RFC3597, except for fields
in a record rather than a BLOB for the record itself.
RFC3597 is fine for an RRTYPE with only one RDATA element/structure, but
not for complex RRs.
So, this problem on sub-field encodings has arisen from ignoring RFC5507
(regardless of why it has been ignored).

There is a pertinent question about any method of addressing this gap:
should it be limited to SVCB (part of this draft), or its own thing?
I can see valid arguments either way.
If it is a standalone thing, that would seem to encourage, rather than
discourage, ignoring 5507.
If it is part of SVCB, it would not be expected that an authority server
would support that outside of supporting SVCB/HTTPS.
Possibly, it could be seen as an enhancement to 3597, in which case the
standalone should definitely point the reader at 5507.

Here's a short list of things I think such a scheme should have:

   - A set of defined presentation-format:wire-format (bidirectional)
   - A method of applying a label to a key number
   - For backward compatibility to any existing implementations, these
   should both be optional, with the existing mapping as the default
   - The set of mappings should be independent of the key numbers to which
   they are applied
   - The set of mappings should be a superset of any mappings used in SVCB
   already, and should include other well-known mappings
   - There should be a mapping type for "flag" where the existence of the
   keyNNN without any data is supported for both presentation and wire formats.
   - This mapping should be used for all of the existing SVCB parameter
   types that already exist, to make implementation much easier and consistent

Here's what I think would work:

   - keyNNNN:label:mapping=value

with the following alternate formats:

   - label=value -- requires label be understood by the server, including
   both the corresponding key number and mapping
   - keyNNNN::mapping=value -- no label included
   - keyNNNN=value -- no label included, default generic mapping
   - keyNNNN:label=value -- label available, default generic mapping

For purposes of examples, here are some suggested mappings:

   - TLVSorted - space-separated sequence of name=value mapped items; wire
   format is a sorted sequence of 16-bit key, 16-bit length, and wire-format
   value defined for the corresponding key (sorted by key number)
      - SVCB and HTTPS formats are TLVSorted
      - Presentation formats do not need to be sorted
   - uint16 - single integer with no leading zeros, maps to 16-bit unsigned
   value, must be a singleton
   - uint16SortedList - comma-separated list of integers between 0-65535,
   maps to a sorted sequence of 16-bit unsigned values
   - base64 - base-64 encoded blob, maps to whatever binary it decodes to,
   must be a singleton
   - flag - has no value in presentation format, has no data in wire format
   (implicitly a singleton)
   - ipv4list - one or more IPv4 addresses in acceptable standard format
   for an A record - if multiple, space separated and double-quote delimited;
   maps to a sequence of IPv4 addresses (A record wire encoding)
   - ipv6list - one or more IPv6 addresses in acceptable standard format
   for an AAAA record - if multiple, space separated and double-quote
   delimited; maps to a sequence of iPv6 addresses (AAAA record wire encoding)
   - CSV - one or more strings, separated by commas, enclosed in double
   quotes, as follows:
      - inside quotes is encoded as the subset of printable-ASCII
      characters in the range of decimal 32 to decimal 126 with escaped
      (backslash) double-quote, escaped escape (double backslash), and also
      permitting other 8-bit values as escaped-decimal values \DDD
      - maps to sequence of (length | value) where each length is uint8 and
      length(value) is between 1 and 255 inclusive.
      - mapped value of one string from the list is the contents of the
      substituted string (e.g. with escape substitutions performed) without the
      enclosing quotes
   - FQDN - a valid domain name; maps to wire-encoding for a domain name
   - The defined field mappings may be added to by <TBD> process (RFC
   required, Standards Action, other?)

Here's what I think the appropriate key/label/mapping should be for the
initial record and SvcParams:

   - SVCB/HTTPS Resource Record is:
      - SvcPriority (uint16)
      - TargetName (FQDN)
      - SvcParams (TLVSorted)
   - SvcParams table keynum/label/mapping:
   - 0/mandatory/uint16SortedList
   - 1/alpn/CSV
   - 2/no-default-alpn/flag
   - 3/port/uint16
   - 4/ipv4hint/ipv4list
   - 5/ech/base64
   - 6/ipv6hint/ipv6list

The specifics for alpn and CSV are somewhat novel, I realize, but I think
they are sufficiently unambiguous and well-defined to enable 2-way mappings
of arbitrary binary blobs of up to 255 characters, so can handle any
potential ALPN value.
Thus, the example used of foo\\,bar,h2 would be, as a CSV, "foo,bar","h2",
and in wire format would be "\x00 \x11 \x07 foo,bar \x02 h2".