At 3:42 PM +0000 9/30/08, [EMAIL PROTECTED] wrote:
> >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.
perhaps I was not clear. I expect that keys
of different lengths adn validity periods will be the
norm. I cna not conceive of a workable model that shares
a single key length/validity period for any key, anywhere
in the namespace.
Ah. We agree, then. Nothing that I put in my proposed changes
mandated any particular length or validity period, I believe.
> > > 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.
can you seriously assert that the keys used to sign a TLD that
gets perhaps a couple dozen changes per year should have the
same characteristics as the keys used to sign a zone
with 200 updates per minute or a zone recording DHCP leases that
last no more than 15 minutes and do it with a straight face?
I never said "should have". And, yes, I fully believe "could have".
i didn't think so.
That's fine, but it would be helpful for you to back it up with an
explanation that could lead to text changes. Given that you have
numbers above, please show how the different key sizes that you are
recommending affect the zone signing.
> > > 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?
augmenting your text - "... will ebcome bogus WITHIN A GIVEN
TRUST HEIRARCHY."
and dropping "until the trust anchor is corrected" ... the
trust anchor
is perfectly fine for a divergent trust heirarchy and should
not be "corrected".
Got it. That looks good to me.
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
