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

Ilari Liusvaara <> Tue, 24 September 2019 15:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F3891208F7 for <>; Tue, 24 Sep 2019 08:32:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ah2moNCYrgIa for <>; Tue, 24 Sep 2019 08:31:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5C7301208F6 for <>; Tue, 24 Sep 2019 08:31:56 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82DDD14F8; Tue, 24 Sep 2019 18:31:54 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id 6djsrodJCVBg; Tue, 24 Sep 2019 18:31:53 +0300 (EEST)
Received: from LK-Perkele-VII ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 141C7286; Tue, 24 Sep 2019 18:31:49 +0300 (EEST)
Date: Tue, 24 Sep 2019 18:31:48 +0300
From: Ilari Liusvaara <>
To: Erik Nygren <>
Cc:, Ben Schwartz <>, Mike Bishop <>
Message-ID: <20190924153148.GA2027159@LK-Perkele-VII>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [TLS] Fwd: SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Sep 2019 15:32:00 -0000

On Tue, Sep 24, 2019 at 09:21:25AM -0400, Erik Nygren wrote:
> Following the discussions in Montreal (as well as with some of the ESNI
> authors),
> we refactored the HTTPSSVC draft to make it more general.  The hope is that
> it could be an alternative (or replace the need) for a distinct ESNI record.
> The draft generalizes to a protocol-agnostic SVCB record, but also specifies
> an HTTPSSVC record for the HTTP(S) use-case.
> Based on discussions with various chairs, the plan is to call for adoption
> in the DNSOP WG.
> Comments/feedback are most welcome.
> From: <>
> Date: Mon, Sep 23, 2019 at 7:01 PM
> Subject: New Version Notification for
> draft-nygren-dnsop-svcb-httpssvc-00.txt
> To: Mike Bishop <>be>, Erik Nygren <>rg>,
> Benjamin Schwartz <>
> Name:           draft-nygren-dnsop-svcb-httpssvc
> Revision:       00
> Title:          Service binding and parameter specification via the DNS

Couple comments:

- Is there need for two resource records? It seems like the two uses
  could be distinguished by starting point.
- What about starting point of protocols that have defined name for
  SRV records? That thing is of form _foo._tcp.domain.example
  (or _foo.udp.domain.example).
- One possible use for AliasForm with '.' would be to signal that
  this service does not exist (IIRC, some other rrtype had special
  "this does not exist" value).
- It seems like ALPN and port are fundamential and would be better
  being their own fields, instead of attributes.
- This could be defined to carry out TLS upgrade for any protocol
  that uses it. However, one would need to allow ALPN to override the
  behavior (e.g., HTTP/3 needs to change transport from TCP to UDP).
- To me, ipv4hint/ipv6hint seem very bad ideas, as they break
  normalization and ownership, drastically increasing odds for errors.
- I would not speculate about records for DNS authorities looking
  anything like this. That RRtype will be very special snowflake.