[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Andrew Sullivan <ajs@shinkuro.com>
Cc: EPP Provreg <ietf-provreg@cafax.se>
From: Ray.Bellis@nominet.org.uk
Date: Mon, 1 Feb 2010 13:45:15 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1265031927; x=1296567927; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[ietf -provreg]=20rfc4310bis=2003=20AD=20Feedback|Date:=20Mon, =201=20Feb=202010=2013:45:15=20+0000|Message-ID:=20<OF02E FD312.E4D033F7-ON802576BD.004AB355-802576BD.004B8E55@nomi net.org.uk>|To:=20Andrew=20Sullivan=20<ajs@shinkuro.com> |Cc:=20EPP=20Provreg=20<ietf-provreg@cafax.se> |MIME-Version:=201.0|In-Reply-To:=20<20100128164249.GE513 3@shinkuro.com>|References:=20<C787106F.3718F%jgould@veri sign.com>=20<OF290E454A.30980263-ON802576B9.00576302-8025 76B9.0057F86A@nominet.org.uk>=20<20100128164249.GE5133@sh inkuro.com>; bh=64RMSStL9ogbKJRhlfe2XVeOZPpG8k6jOgBTDNX8u8I=; b=HS/Knv0YBPrYgi/LJ9ZlfqzP0MwCl+M0eDpfK+GPupRbniQLGF//fH2M AtyYm7dtBN6GJKx9Li3NN1B9awnuUWvZPkldqqpiWS6QauVh4VkJGTNtb 2z4lDw/ymzGyxwa;
DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=LVkjFt8I2t884zGArEI89l1kPdpefBPXwxXorNIqW2O/WkMiWf2UFcpd xnR2RccP/5QL8rtJhQXaq30iSyrLfSav17hxX/8XHjxIRMyHo9edIpJBM Bj2upj/TnzJdIER;
In-Reply-To: <20100128164249.GE5133@shinkuro.com>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: [ietf-provreg] rfc4310bis 03 AD Feedback


> The idea is that the child might want to have some maximum above which
> it doesn't go, so that the child can roll keys in a predictable way.
> This unfortunately ignores the effects of the RR TTL on the whole
> issue, and IMO is a foot-gun loaded for bear, because it makes it
> trivially easy to set the RRSIG short enough that an RRSIG expires
> while in cache.  Without a knob to control TTLs, I don't know why
> you'd allow this to be adjusted.
I also can't see how it relates to rollovers - as later messages point out, the signature lifetime in the DS RRSIG applies to _every_ DS record, and is not on a per-DS basis.  Hence you can't have a different life time on different keys as they're introduced - all you _might_ do is reduce the lifetime on _all_ keys.

Our initial assessment is that we can see no need to expose this parameter to child zones.  The signature on the DS RRset in the parent zone is created by the parent, and is the way that the parent guarantees to anyone who retrieves the DS RRs that the information is from the parent and has not been altered in transit.  All the child should be concerned about is data in the DS record; proving the authenticity of that data is the parent's responsibility.

Ray
Home | Date list | Subject list