[dbound] draft-brotman-rdbd

"A. Schulze" <sca@andreasschulze.de> Fri, 29 March 2019 17:06 UTC

Return-Path: <sca@andreasschulze.de>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5665A12025D for <dbound@ietfa.amsl.com>; Fri, 29 Mar 2019 10:06:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=andreasschulze.de header.b=ZkA5CVAE; dkim=pass (2048-bit key) header.d=andreasschulze.de header.b=w3dudAi3
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3l1x_-2qhiCR for <dbound@ietfa.amsl.com>; Fri, 29 Mar 2019 10:06:30 -0700 (PDT)
Received: from mta.somaf.de (mta.somaf.de [IPv6:2001:470:77b3:103::25]) (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 5EC5C120254 for <dbound@ietf.org>; Fri, 29 Mar 2019 10:06:30 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=andreasschulze.de; i=@andreasschulze.de; q=dns/txt; s=ed25519; t=1553879187; h=to : from : subject : message-id : date : mime-version : content-type : content-transfer-encoding : from; bh=SqKIUGsTj+aOyoOU9fmvX8FfRk4bYCyuO0pbH90yUWQ=; b=ZkA5CVAErehD7dYXbwN2KEs3hhu92eVIQkpaXwfkUj3RPIf5r3aqVWTU a6tdWXkyRtNwjwzZQuFjZT2wJ52TBA==
To: dbound@ietf.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=201903-A9C5ADDF; t=1553879187; x=1558879187; bh=SqKIUGsTj+aOyoOU9fmvX8FfRk4bYCyuO0pbH90yUWQ=; h=To:From:Subject:Message-ID:Date:Content-Type:from:reply-to: subject:date:to:cc:content-type:message-id; b=w3dudAi3K/pnmLTMgUMEf1IeckS+ilMdAS4ntx87bxW6/kohSOHGwOjS+9wr1iMgy AFh1RMiUEomErPxo0FLFL25i+x/+J/pgfSh8uZax5ya9cRgOheI5yvdmyNaX84A9/D CzCJew+GEh1eR3pKtg3am1ZKCrN7qYYEI3sFLofvqnOEKJEPBg3hZKYpYEj9gjIOJ+ VjHkntaVRpg9/8H1oynUzMWcOr09v0Ovk/Gv6jrFgfpkD8RP3t5gX7mz+aMSKtlf4e +d7BqRC7JodVx8uoqfJjrGNh06N6JGEajsv01dnYQOg29S3ZKQq5nUa3Q9EouDxr86 JA9ft4qK9FxqQ==
From: "A. Schulze" <sca@andreasschulze.de>
Message-ID: <f6862326-40e1-d804-cefe-e63c79a0534d@andreasschulze.de>
Date: Fri, 29 Mar 2019 18:06:35 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/gB5uOlKgPCCyB4bgYwHhtUuiwG0>
Subject: [dbound] draft-brotman-rdbd
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Mar 2019 17:06:33 -0000


I read the draft. In general I like a possibility to express relationships.
As noted by Warren at the mic, there is also a desire to express "no relation" explicitly.

som thoughts/questions:
> We include an optional digital signature mechanism...
why optional? without any signature wouldn't it possible to any third party to express any relationship?

> RDBD is intended to demonstrate a relationship between registered domains, not individual hostnames.

where is the border? May publicsufficlist help defining them?

2.1 / 2.2
as zone apex is likely to be overloaded today, defining something like _drbd.example covering RDBDKEY and RDBD data comes in mind.

1, mention DKIM like mechanisms, but 2.1 introduce to me unexpected "The RDBDKEY RR uses the same registries as DNSKEY for its fields."
.. confusing

> The trailing "." representing the DNS root MUST NOT be included in the to-be-signed data,
> so a relating-domain value above might be "example.com" but "example.com."
what's the reason for not making the root explicit?

the current concept I understand as every random domain can express itself as related domain to a relating domain.
That allow enumeration via passive DNS technics for example without putting any effort in validating signatures.
I understand the desire to allow such enumeration but a more privacy friendly version [1],[2] is welcome, too
And, yes, DNSSEC shouldn't be optional. Re-using existing DNSKEYs may make the signature/validation stuff easier.


[1] https://mailarchive.ietf.org/arch/msg/dbound/cPUM4AKeowvUPQY3wclWQpAKgEE
[2] https://mailarchive.ietf.org/arch/msg/dbound/tXghAjUAiezkJLA0FlO0Sy__lrQ