Re: [dbound] draft-brotman-rdbd

Scott Kitterman <sklist@kitterman.com> Mon, 01 April 2019 03:51 UTC

Return-Path: <sklist@kitterman.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECAD120005 for <dbound@ietfa.amsl.com>; Sun, 31 Mar 2019 20:51:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=kitterman.com header.b=dK6FnCXM; dkim=pass (2048-bit key) header.d=kitterman.com header.b=T4S8mOgS
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 fXLkLqo_4DIX for <dbound@ietfa.amsl.com>; Sun, 31 Mar 2019 20:51:17 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FC62120049 for <dbound@ietf.org>; Sun, 31 Mar 2019 20:51:16 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id C47FDF80956 for <dbound@ietf.org>; Sun, 31 Mar 2019 23:51:15 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1554090675; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=bDzzuAfY119DnLO3Y0cM2EJ5svMjGm/CikgV7DzSVT8=; b=dK6FnCXMHv8+b8QJACpbIBruQed35nfzgc+xsZ9ckH/S/178m82jQbny eZM+4VS7e8Tq8rYaF5R8dHEM/uvvCQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1554090675; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=bDzzuAfY119DnLO3Y0cM2EJ5svMjGm/CikgV7DzSVT8=; b=T4S8mOgSYnLn7usDpRa3V8zvUYxoro/j/0X+gUv5GYHvNK76KtPYwsjX Q/jHW8H72MxWk8IFvvQDBjjhWtoWBsM8SSjrMadXzcbkHWtVSxOlUg8Wze OKVFPqe5KgY/JsLNs7GY5z2QRPttDhd3+Dp/yJl6Cx6wt9jkLAR07a3WA+ +PEBrgdp9u33mjiyGiQdaWLz/m8jLVKWLpjC//JYf2c5rEohhwHkYdyqbP RbFyf0I21KLywPJqT7inqEUCth87/+qwwhDshmWsiIfoh1f3LX4aOnvy7Z BmOjIeWlOOo/aNQ35TpvaR0fz9ij2m4tluGI9hhXrRA0qBhAqCHv0g==
Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 8C180F8071A for <dbound@ietf.org>; Sun, 31 Mar 2019 23:51:15 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: dbound@ietf.org
Date: Sun, 31 Mar 2019 23:51:13 -0400
Message-ID: <6145507.lIgk3o490W@kitterma-e6430>
User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <e79a869c-62ca-4e8c-7eec-283529ed273d@cs.tcd.ie>
References: <f6862326-40e1-d804-cefe-e63c79a0534d@andreasschulze.de> <alpine.OSX.2.21.1903312230470.10104@ary.qy> <e79a869c-62ca-4e8c-7eec-283529ed273d@cs.tcd.ie>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/tXZj-LM4AuWt8ASO9tHHA7mq5Po>
Subject: Re: [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: Mon, 01 Apr 2019 03:51:20 -0000

On Monday, April 01, 2019 03:44:46 AM Stephen Farrell wrote:
> On 01/04/2019 03:38, John R. Levine wrote:
> > I suppose that if there were some very high value application that
> > depended on rdbd records there might be more of an incentive to use DNS
> > attacks to fake them, but it all seems like a lot of extra work for
> > utterly speculative benefits.
> 
> Questioning the efficacy of rdbd signatures is reasonable but not
> at all the same as a claim to not understand 'em.
> 
> I agree that the efficacy of these signatures isn't a slam dunk.
> The draft says as much. I'd be happy to improve the explanation
> in the text wrt that.
> 
> But the signatures are optional. So if I'm wrong that they're
> useful, then that's ok, you'll be right and they'll not be used.
> Equally, if OTOH but unexpectedly, I'm not wrong, then there'll
> be a method for signing defined as part of the spec.
> 
> What's wrong with that?

It adds some significant complexity to the design.

If the crypto bits have significant utility, then baking the needed protocol 
elements for smooth key rollover (e.g. for DKIM you use a new selector and 
leave both the old and new keys live for $TIME to allow everything that was in 
process to be received and validated before the old key is removed).  Are 
multiple RDBD and RDBDKEY records allowed per domain?

If not, particularly due to cache misalignment, a smooth key rollover will be 
very hard.

Multiple records per domain would also allow for algorithm agility (publish 
both RSA and Ed25519 for transition as needed).

Libraries implementing RDBD would need more dependencies and be more complex 
to deploy.

My suggestion would be to think hard if it's really needed and if so, then 
make it a MUST.  If not, take it out.  It can be added easily enough later, 
right?

I do think the explanation could be clearer.  I was following along with John 
Levine's argument pretty well.  It took me several scans of the draft to 
realize that the signature (RBDB record) is published by the relating domain 
and the public key (RDBDKEY record) is published by the related domain.  Once 
I realized that, it made sense.  A signed record, to the extent you can't 
spoof both domains simultaneously or nearly so, would give added confidence 
that the related domain agrees that that relationship is valid and not just 
examp1e.com claiming to be related to example.com.

As a more general comment, RFC 8301 is the reference for the minimum key size 
of 1024 bits (RFC 6346 is 512).  Also, it might be worth looking at RFC 8463 
(which added Ed25519 to DKIM) to see if there's guidance on putting Ed25519 
public keys in DNS that can be reused.

Personally, I think I like the crypto bit, but if it's in, I'd like to see it 
be a MUST.  Also, do we really need RSA?  There are plenty of Ed25519 
implementations available.  Personally, I think it's simpler to deal with (and 
the public keys are way smaller, which is nice for DNS).

Scott K