Re: [dbound] draft-brotman-rdbd

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 01 April 2019 08:11 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 302FC1200CE for <dbound@ietfa.amsl.com>; Mon, 1 Apr 2019 01:11:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
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=pass (1024-bit key) header.d=cs.tcd.ie
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 1ZgPb6DbMo1L for <dbound@ietfa.amsl.com>; Mon, 1 Apr 2019 01:11:30 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B6312009E for <dbound@ietf.org>; Mon, 1 Apr 2019 01:11:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7D8E1BE2E; Mon, 1 Apr 2019 09:11:26 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZY2L8RT6x_o; Mon, 1 Apr 2019 09:11:24 +0100 (IST)
Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 28555BE24; Mon, 1 Apr 2019 09:11:24 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554106284; bh=UG6hxTOHGFGgn2HMYCn7pPWr3TxqdL0gy3MAhis7Agk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=QTCy/nOtPEygdoFTx1Rxv9Aaj+Hc2zWsqyNGmz7In7/pnocRUqJ8cuf1YmtVGFjSP zu6SKE6E+pMeBj0eNKUSi9FeA7Q1pBXeOZvRpdxmUiDh4DLG7F3W3/AKD1LxDfVcSp O1ZT8WT6uMvCyz37WVDZ5cma8KgOBaT7pKtWgoI4=
To: Scott Kitterman <sklist@kitterman.com>, dbound@ietf.org
References: <f6862326-40e1-d804-cefe-e63c79a0534d@andreasschulze.de> <alpine.OSX.2.21.1903312230470.10104@ary.qy> <e79a869c-62ca-4e8c-7eec-283529ed273d@cs.tcd.ie> <6145507.lIgk3o490W@kitterma-e6430>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <2395e7bc-f634-a882-9229-147fa7febf37@cs.tcd.ie>
Date: Mon, 1 Apr 2019 09:11:22 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <6145507.lIgk3o490W@kitterma-e6430>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FOHTjj0K9WpgI4Ij4zngTYoHassEyoIyL"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/P48n-D09e30MlVO32Dkwz6bwtMA>
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 08:11:33 -0000

Hiya,

On 01/04/2019 04:51, Scott Kitterman wrote:
> 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.

True.

> 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?

Yes.

> 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.  

Also a reasonable position.

> It can be added easily enough later, 
> right?

Not sure TBH. I think adding rdbd-signatures later would mean
defining another RRTYPE, which is about as much work as this.
I've no idea how that'd affect deployment either.

> 
> 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.

Will try clarify those issues, thanks.

> Personally, I think I like the crypto bit, but if it's in, I'd like to see it 
> be a MUST.  

Fair enough.

Other inputs on this topic appreciated! I guess the choices are:

1. take out rdbd-signatures entirely, as per John L I guess
2. leave rdbd-signatures optional, as per -01
3. make rdbd-signatures mandatory, as per Scott K

(I consider those are independent of DNSSEC as we're signing
across and not downwards with rdbd-signagures.)

> 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).

True, but I'd argue to keep RSA for now at least as e.g.
openssl's command line tools don't yet have ed25519 (for
internal API reasons, so not clear when that'll be fixed).
RSA could get dropped along the way I guess if things
change sufficiently before this draft is done.

Cheers,
S.


> Scott K
> 
> _______________________________________________
> dbound mailing list
> dbound@ietf.org
> https://www.ietf.org/mailman/listinfo/dbound
>