[dnssd] draft-pusateri-dnsop-private-subdomains-01

Tim Wattenberg <mail@timwattenberg.de> Sun, 24 March 2019 20:57 UTC

Return-Path: <mail@timwattenberg.de>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15CB1200F5 for <dnssd@ietfa.amsl.com>; Sun, 24 Mar 2019 13:57:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 0nAEXXLkrrrG for <dnssd@ietfa.amsl.com>; Sun, 24 Mar 2019 13:57:55 -0700 (PDT)
Received: from mx2.mailbox.org (mx2a.mailbox.org [IPv6:2001:67c:2050:104:0:2:25:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8CC51200F1 for <dnssd@ietf.org>; Sun, 24 Mar 2019 13:57:54 -0700 (PDT)
Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id D1812A1300; Sun, 24 Mar 2019 21:57:52 +0100 (CET)
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp2.mailbox.org ([80.241.60.241]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id dR-KfgZxohn6; Sun, 24 Mar 2019 21:57:48 +0100 (CET)
From: Tim Wattenberg <mail@timwattenberg.de>
Content-Type: multipart/signed; boundary="Apple-Mail=_1D9A5779-76E6-4AFE-8A0C-0A15AB18251F"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Message-Id: <92D17A70-1AC3-44C7-97C1-817536D40BD2@timwattenberg.de>
Date: Sun, 24 Mar 2019 21:57:45 +0100
To: dnssd <dnssd@ietf.org>, Tom Pusateri <pusateri@bangj.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/RfdCIGbjtQWPJ5Go2ibimj1c1x4>
Subject: [dnssd] draft-pusateri-dnsop-private-subdomains-01
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Mar 2019 20:57:58 -0000

Tom,

I just read your draft-pusateri-dnsop-private-subdomains-01.
Here’s some immediate feedback:

General:
I see to concepts in this document, one being the possibility to register a subdomain and prevent others from (mis-)using it by adding/changing/deleting records (Sec. 3) and one being the idea of keeping the records private and only queryable by the owner (Sec. 4). Having just finished reading, I’m not sure if I like those two to be „mixed up“ in one document. The first case seems applicable to me without insisting on the second one.

Sec. 3.1:
I’d consider adding some text about FCFS being a possible mechanism as well (not strictly necessary, but what immediately came to my mind).

What happens if "user“ tries to claim "<notuser>._pvt.<domain>.“ (which is not allowed by the policy of the administrative domain)?
You might want to respond with RCODE REFUSED?

I’m not yet convinced of using RCODE YXRRSet (instead of REFUSED), if the zone does already exist (although this would allow a distinction to the case described in the previous paragraph). Maybe I’m just sticking a bit to heavy on what RFC 2136 says ("Some RRset that *ought* not to exist, does exist.“)... 

I think you have a typo in "In response, appropriate NS records for "<user>" will be created in the "_pvtr.<domain>.“ and […]“, or is it "_pvtr.<domain>.“ (sic, note the r) on purpose?

Sec. 3.2:
"Then the message is signed with the subdomain owner's private key.“
If the KEY-change is due to the private key being changed, I presume this is *old* private key?

Sec. 4.1:
Just to make thinks clearer, I’d like an addition along the lines "All queries *to "<user>._pvt.<domain>.“* MUST be signed with the private key of the owner.“. Also I’d consider allowing an unsigned query of SOA records in order to allow checking for existence before trying to claim a subdomain.

I’m happy to discuss your feedback on feedback – here, in the session or during the week ;-)
	Tim