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

Re: DS Algorithm selection and SHA1 deprecation



> >>>>> On Wed, 07 Dec 2005 12:09:28 +1100, Mark Andrews <Mark_Andrews@isc.org> said
> :
> 
> Draft> Because zone administrators can not control the deployment support of
> Draft> SHA-256 in deployed validators that may referencing any given zone,
> Draft> deployments should consider publishing both SHA-1 and SHA-256 based
> Draft> DS records for a while.  Whether to publish both digest types
> Draft> together and for how long is a policy decision that extends beyond
> Draft> the scope of this document.
> 
> Mark> I think this needs to be strengthend.  This currently allows
> Mark> you to use SHA-1 for one algorithm and SHA-256 for a different
> Mark> algorithm.  This really needs to be made pair-wise.  If you
> Mark> choose to publish both then you need to do this for every
> Mark> DNSKEY you are generating a DS for.
> 
> The rather strong previous consensus was not to dictate operational
> requirements at all.  Thus I think what should be added to alleviate
> your concerns with different algorithm choices:
> 
>   Because zone administrators can not control the deployment support
>   of SHA-256 in deployed validators that may referencing any given
>   zone, deployments should consider publishing both SHA-1 and SHA-256
>   based DS records for a while.  If multiple algorithms are used for a
>   given name then both SHA-1 and SHA-256 based DS records should be
>   published for every algorithm.  Whether to make use of both digest
>   types and for how long is a policy decision that extends beyond the
>   scope of this document.

	I'd still prefer the following change

	s/algorithm/algorithm and preferably for every DNSKEY for which a DS is being generated/
	
	One per algorithm is the minimum required to prevent the
	delegation going unsecure.

	
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>