Paul is not looking at the operations of DNSSEC as something that WILL by
its very process need to be Court Admissible Evidence and so that is not
being considered here.
Todd Glassey
----- Original Message -----
From: "Paul Hoffman" <[EMAIL PROTECTED]>
To: <dnsop@ietf.org>
Sent: Tuesday, September 30, 2008 8:05 AM
Subject: Re: [DNSOP] Proposed changes to RFC 4641: differentiation between
trust anchors and keys with parent zones
At 11:58 AM +0000 9/29/08, [EMAIL PROTECTED] wrote:
> Remove all of 3.1.2. Longer keys are not useful because the crypto
guidance is that everyone should use keys that no one can break. Also,
crypto guidance from whom?
That guidance, as it were, is in RFC 4641.
longer keys are useful for several
reasons.
Please explain. Using keys longer than the actual security needs
waste CPU cycles both for the signing zone and the recursive DNS, and
also waste bandwidth.
> it is impossible to judge which zones are more or less valuable to an
value is in the eyes of the zoen admin, not a random hacker.
Of course. If you have proposed text to help a zoen admin put a value
on their zone that can be translated into signing key lengths, please
post it.
> Remove the first phrase of the fourth paragraph of 3.3. At the end of
the paragraph, add:
Note that if a trust anchor replacement is done incorrectly, the
entire zone that the trust anchor covers will become bogus until
the trust anchor is corrected.
manipulation of the TA/SEP nonces fundamentally changes the
validators view of trust.
one presumes that your assuming a single trust heirarchy and
wiggling one piece to give
a parallax view creates "bogus" data -from the perspective of
one view of a trust heirarchy-.
alternate trust heirarchies will emerge.
Fully agree; they already have. How does that affect the change that
I proposed?
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.173 / Virus Database: 270.7.5/1700 - Release Date: 9/30/2008
11:03 AM
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
