Re: [DNSOP] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00

Jan Včelák <> Wed, 25 September 2019 16:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C3DB120072 for <>; Wed, 25 Sep 2019 09:18:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a5OujoBpbUC6 for <>; Wed, 25 Sep 2019 09:18:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 80158120013 for <>; Wed, 25 Sep 2019 09:18:55 -0700 (PDT)
Received: by with SMTP id f15so4224740vsq.6 for <>; Wed, 25 Sep 2019 09:18:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=aDWfP4PGVE7gX4ql8JQtmfdJLnJ4gN4PBi7sn0Dsm28=; b=NVtxjfgTrOr+zxZ9TkCxjXMCeI3PXzwC9w4s1PnxHH03ik4GrjTmZLrpYz9N+LZvej oKbC2kQ3YQwu02fh8nWjJzgYPQkMaFyCRWqXtJDo21bT+oWPIicvxim55YeH1mGPDUjk B/ng8cYe+KzDUsp+pXH5kF4qgcHWhk5oOzHUI=
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:content-transfer-encoding; bh=aDWfP4PGVE7gX4ql8JQtmfdJLnJ4gN4PBi7sn0Dsm28=; b=OhXpaXd9kUzNXbYiH3MmQvTsYrIQQ97HyCYLCfRF6YrbYGF/gUz16+oEwjhrjgsPVg 9cIuKJjlRDukKKhrWikbDTKAPsFbTYKbp0HmmlKvupfkRKDxWibLU17gVJ4nLT5ojbhE XomUbRAayPl0VubnFfNPSjcNEswrVxzTGpL1QNM8sxKI1ttdKFw8BPbGq2am10sz5XKJ 4GT4lxLactyx5YIi6NMKGHZd88txj/Qca/evT1ysijar8IFsZ9kdleTlVWoRT+RXLIAy iH/sGbcKi4fpoON/r56Oy5sA3L9qs8EuHk3ynFypF91NLxk+Q5MxjKeAYrrHjT8iyjug ECEw==
X-Gm-Message-State: APjAAAU6FE1IAhIIJ8TBYvev3LuPjqT8Pmy1j10T1STUFirHsSVvhZes kndMa0iZBDnhZCuM/2bf9xKmWOPeq7eoyEn6aNxQnT0Az7OSjhik
X-Google-Smtp-Source: APXvYqwqETXm97AOWRRIWiT0JRkRpZezYpJ7h/pUVAXVIR9OZXW8XO1b/r6XppLkj2itCx8AY2VqoJVwkNClphIWf+E=
X-Received: by 2002:a67:ec4c:: with SMTP id z12mr5561010vso.28.1569428334003; Wed, 25 Sep 2019 09:18:54 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= <>
Date: Wed, 25 Sep 2019 18:18:43 +0200
Message-ID: <>
To: dnsop WG <>
Cc: Erik Nygren <>, Ben Schwartz <>, Mike Bishop <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00
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, 25 Sep 2019 16:18:58 -0000

On Tue, Sep 24, 2019 at 3:19 PM Erik Nygren wrote:
> Following discussions around the "HTTPSSVC" record proposal in Montreal with the DNSOP, HTTP and TLS WGs, we've updated what was previously "draft-nygren-httpbis-httpssvc-03".  The new version is "draft-nygren-dnsop-svcb-httpssvc-00".   This incorporates much of the feedback from the WG discussions, as well as feedback from discussions with the TLS WG (as we'd like to see this replace the need for a separate ESNI record).

I support adoption of the draft by this working group.

I generally like the content. I think the HTTPSSVC specifics leak into
the generic SVCB specification a little but that could be polished
later and I haven't noticed any outstanding issues.

One thing I'm concerned about is the SvcParamKey wire format (and
registry). You propose that each parameter would have a code point and
a value encoded in a form specific to the parameter type. On one hand
it will lead to compact encoding but on the other hand an introduction
of new parameter type may become complex for the implementers. Have
you considered encoding the parameters in a free form? Maybe as a
string, similarly how SPF configuration is stored in the TXT record.
It could look like this:      7200  IN HTTPSSVC 0 ""  7200  IN HTTPSSVC 2 "alpn=h3
port=8003 esnikeys=\"ABC...\""