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

Ben Schwartz <> Wed, 25 September 2019 17:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A936120808 for <>; Wed, 25 Sep 2019 10:17:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 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, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 5HQdiaXYGbzG for <>; Wed, 25 Sep 2019 10:17:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9A94E12022C for <>; Wed, 25 Sep 2019 10:17:18 -0700 (PDT)
Received: by with SMTP id v2so680802iob.10 for <>; Wed, 25 Sep 2019 10:17:18 -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=j9Q493r4EzZTj+tiasIwymk/kx78kvSdBSCk0cjrUUs=; b=tnxSbHQZUI+dtI+lp48oeuV3Myx9wncKY9K68XurVhj4DAfaIIQNw6tu7oG3fhU0yS 0M6JMWmYZJpLbAWabgN1abwxpVCoZCqv570T2FL8/BL2OaEgB7SaCiqS/90eyb467VnQ TqZEQmtnLQEYYILK9jC1Rnne7cR40jRvK7fSGwLI50JMkXcbSObWvbd48tIHlg/1qFAV fBif9C5juFnOU38ZP6LXMsYNQwrv/3rsAP8q56aBsT+Fm77d66XIS9YrBl6JIU/PR9cU /95BC1xSXwEQ0rOoHxSHpu2tPi0Nb6B2pdSeIv9xtakFi5ZsXSw6OAvExRVYSi+NurQ1 Qh6g==
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=j9Q493r4EzZTj+tiasIwymk/kx78kvSdBSCk0cjrUUs=; b=Ch+yyp4c/mXSRjAKNh7+CLwxwj11c8l3FfBykROx8g1jJr2LCOgw8cxl2ncJLViRoD 0hx87/IaWf7vPmLLevU1B+HqN9K9XYx48ah3RUQGK85JVpiGTkNApPvSAu/9yXzYv5FP G800evuWufSWF5dN2aF99MyMn5cW0i08reaheUrLeWzm1SbPcxjrPHQlJKBk81IlVRb4 KRDU15xiITmwl43WnZSzlsWSa6hzEjlDLgoB4Az2IfeBc0ih+40fRk1S4uE/coHkHRNz C88CXmf2rYhktUjR6ef5Hc62mzO88sD8sh+pTeBfk8E4sj7kAXLXhBMCtsCYPmTHYKEY abww==
X-Gm-Message-State: APjAAAULVJYljQzAhfpfwO9MUKTfdeCKVGg+oRlXgGPHW2ZtOJYS6lWr rr8igCkwGiWJ+zYUcMxbyCqqDRQfD3xwApksgqmWneZV+Ps=
X-Google-Smtp-Source: APXvYqxXw41Q+aH4WN1TKNsH/YTP9W2HyrzEvEffQQwCGgxC1EyArHu4nJ0YRPwfz4q9MdZ3OmExhfP+e/paom18s40=
X-Received: by 2002:a6b:6101:: with SMTP id v1mr407092iob.153.1569431837461; Wed, 25 Sep 2019 10:17:17 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Wed, 25 Sep 2019 13:17:04 -0400
Message-ID: <>
To: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= <>
Cc: dnsop WG <>, Erik Nygren <>, Mike Bishop <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000003562b0059363d3a1"
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 17:17:23 -0000

On Wed, Sep 25, 2019 at 12:18 PM Jan Včelák <> wrote:

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

The original proposal used a text encoding similar to your description.  We
changed to a key-specific encoding due to complaints about the inefficiency
of base64-encoding ESNI keys.  I think the inefficiency of base64 encoding
is tolerable, but we adopted the feedback in favor of a binary encoding.

If the working group would prefer a textual wire format, that can certainly
be done.

The current draft attempts to minimize complexity for implementers by
offering a fully generic encoding for unknown key types.  For example,
"alpn=h3" can also be expressed as "key1=h3", and "port=8003" can also be
expressed as "key2=\031\067".  This encoding may not be convenient, but
hopefully it will reduce the burden of supporting new parameter types.

All of the value formats mentioned in the draft (raw, uint16, base64, IPv4,
IPv6) are already common in zone files.  If future parameters also stick to
popular formats, new parsing code should be minimal.

> Jan