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

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 24 September 2019 15:32 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3891208F7 for <tls@ietfa.amsl.com>; Tue, 24 Sep 2019 08:32:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ah2moNCYrgIa for <tls@ietfa.amsl.com>; Tue, 24 Sep 2019 08:31:57 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C7301208F6 for <tls@ietf.org>; Tue, 24 Sep 2019 08:31:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 82DDD14F8; Tue, 24 Sep 2019 18:31:54 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id 6djsrodJCVBg; Tue, 24 Sep 2019 18:31:53 +0300 (EEST)
Received: from LK-Perkele-VII (87-100-246-37.bb.dnainternet.fi [87.100.246.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (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 <ilariliusvaara@welho.com>
To: Erik Nygren <erik+ietf@nygren.org>
Cc: tls@ietf.org, Ben Schwartz <bemasc@google.com>, Mike Bishop <mbishop@evequefou.be>
Message-ID: <20190924153148.GA2027159@LK-Perkele-VII>
References: <156927967091.17209.1946223190141713793.idtracker@ietfa.amsl.com> <CAKC-DJi4EHz5CCAqRj_cYTVygiuo0s2QGaPLCct6e9Bh1mXaXQ@mail.gmail.com> <CAKC-DJgUt-H4-EQ3pvBL8_-UEUty3kQwTyh_Adtp3ORtiZOySg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAKC-DJgUt-H4-EQ3pvBL8_-UEUty3kQwTyh_Adtp3ORtiZOySg@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/7PT6Y-rcWrlNG6loLoF9MsruPV8>
Subject: Re: [TLS] Fwd: SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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: <internet-drafts@ietf.org>
> Date: Mon, Sep 23, 2019 at 7:01 PM
> Subject: New Version Notification for
> draft-nygren-dnsop-svcb-httpssvc-00.txt
> To: Mike Bishop <mbishop@evequefou.be>be>, Erik Nygren <erik+ietf@nygren.org>rg>,
> Benjamin Schwartz <bemasc@google.com>
> 
> Name:           draft-nygren-dnsop-svcb-httpssvc
> Revision:       00
> Title:          Service binding and parameter specification via the DNS
> (DNS SVCB and HTTPSSVC)

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.


-Ilari