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

Brian Dickson <> Thu, 20 May 2021 01:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B3313A27E2 for <>; Wed, 19 May 2021 18:32:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, 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 jWusEXf_UqLc for <>; Wed, 19 May 2021 18:32:37 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8059A3A27E1 for <>; Wed, 19 May 2021 18:32:37 -0700 (PDT)
Received: by with SMTP id a4so2958733ljd.5 for <>; Wed, 19 May 2021 18:32:37 -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=tNNRXMJv/K/7is5ZttMlbiiKoiXnCxDSVjFnFJaWFlQ=; b=bacyLhTo7EgjSv9w0vSXpM8lmMx/xaARu4jopWbvlq6L2hC2eSRlz+gqfmsfjSCLAb sKoggLzUQqWVc9/4KwKJDQ+d9ELPnr2SrRNl2btAUJormeCmbnz875W7m2bV4rKRCcD+ SKJoPgxgo79uA3XlDXIHIGzhmBwt1d2vulril4RqROFs/eDAegpDTctsXNw3MxaPDy70 fzoSKjYzIcTZ+fJCobOX72leOXVI3j5zMB+oUdjmaG8/vOjSSx0aDskPWm7HFsnxU+vt SvSeSG3as8LQSK5s6lCZ+mqef6d6rVFb1pnpgk3sngD+kOkmBcqev90c/AWcFTm62b11 XjSw==
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=tNNRXMJv/K/7is5ZttMlbiiKoiXnCxDSVjFnFJaWFlQ=; b=lcmxNUqZkmtk4EGwSDKs9FS4oiq/WGLd3aPRS1pLz3fy/qEvO8r7Mxv6jEygEuT5UQ 4swQf/pXaFEGnrSRMPVLCBYoc7wsJFty5X7y0olM2ljSbc5VRyTTFew0haxkWFXOnjLd 5FYKUFamly+gDrZPWb/aDlh+9E/YA/9c6x9J6DATjS3yOtG9it9Abt5aXzmir+MEfla5 ss8+1ZRWv/S0w6VQFbjm+EkRVXkialdDawyd+rdjDe/oN3s/wO7SC9Uwud8LkZ7QSQvG 6ciWUMwNzG+b17nUkxH0m8k1WAfklSiEbyPdSoE8BLEXBR9wYKrA8X6B5H22nuCsX8Rn 3qFA==
X-Gm-Message-State: AOAM530iog7cc2a8ZllhenD3lk3HBvs6rFCZjp3y6XrUMGWxtP4ycqmf Mo0FeHDskLoW29Jb3DjaqSrmAx6Ijd0p1ww8KE4=
X-Google-Smtp-Source: ABdhPJyM9aAchuqd+kMpbEIRSjxUfcTa1puvk5VfFhUJ+kXEzlbTP50ra5cp0dPIBNE/va3BRiYwRyH78/YAsi060lc=
X-Received: by 2002:a2e:8717:: with SMTP id m23mr1391759lji.161.1621474354088; Wed, 19 May 2021 18:32:34 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210512213903.D5F1F7AA827@ary.qy> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Wed, 19 May 2021 18:32:22 -0700
Message-ID: <>
To: Martin Thomson <>
Cc: " WG" <>
Content-Type: multipart/alternative; boundary="000000000000e34f6105c2b8eae5"
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: Thu, 20 May 2021 01:32:42 -0000

On Wed, May 19, 2021 at 5:52 PM Martin Thomson <> wrote:

> On Thu, May 20, 2021, at 10:35, Brian Dickson wrote:
> > I was under the impression that the extensibility is for the SVCB type,
> > and not strictly needed for HTTPS.
> It is absolutely needed for HTTPS.

I'm not saying I doubt you, but maybe you could explain what you think
would need to be added as an SvcParam, that would not be an ALPN, port,
ech, ipv4hint or ipv6hint?

Specifically that would need to be included as part of the one-lookup-DNS
value that is needed prior to making the TLS connection?

Is it one of those things that are "Well, we think we might need
something", or is it "We already know something we need"?

Is it something you know about and intend to deploy soon, like within the
next couple of years?

If not, how would SVCB NOT be reasonable to use instead of adding to the
HTTPS record?

(There's a reason I'm not suggesting making SVCB non-extensible, or
touching any aspect of the SVCB thing itself.)

Note that more ALPN values are supported, and how those are
defined/used/etc are really not relevant to the structure (wire format) of
the records (HTTPS or SVCB).

HTTPS needs transport, port number, name, and maybe some hints for IP
addresses, plus the new encrypted SNI.
I'm at a loss for what else could even be used for establishing a TLS
connection, in terms of anything/everything involved in TLS1.3?
The transport is signaled via ALPN, alternate ports can be used, addresses
are required, and name/SNI/ESNI/ECH are part of the TLS establishment.
Everything else is in-band within TLS itself (e.g. certificates) or
obtained from other sources (e.g. TLSA from DNS).

Is there something I'm missing that would be needed as part of the TLS
connection, from DNS ahead of time?