On 04/18/2011 16:14, George Barwood wrote:
----- Original Message -----
> From: "Paul Wouters"<p...@xelerance.com>
On Mon, 18 Apr 2011, George Barwood wrote:
(1) It's my belief that almost all Zones except for the root zone
should NOT use a KSK/ZSK split. With the signing of the root zone
and many TLDs, manual distribution of trust anchors is likely to
be uncommon.
Not true. Any responsible organisation will configure their own
zone's trust anchoes in their resolvers, so they can operate
internally when their WAN/UPlink is down.
Possibly. But I think this will be quite rare, and will only apply to
organisations with very significant resources (maybe governments).
I would do this at any enterprise I was involved with.
I really doubt the significant extra complexity of managing these trust
anchors is likely to lead to an overall increase in security. How are
you going to distribute them?
The same way that I would distribute all of the other name server
configuration files.
If you have a distribution mechanism (
other than the public one ) then you can presumably update the trust
root config in a timely way when needed, so nothing is gained.
I'm not sure how that's germane to Paul's point. I'm going to have the
root zone trust anchor configured already, but I would not want to have
to configure all of the relevant TLD trust anchors as well. I would much
rather configure the trust anchors for _my_ zones that I care about
being able to continue functioning should the big-I Internet be
unavailable.
(2) There is no point in using a larger key size than the
smallest key size in the parent chain
See 1) Those will benefit from additional strength that seems
excessive to any parent.
I really doubt security would be improved in practical terms. The
extra complexity of non-standard configuration would probably
outweigh the minute benefit of longer keys, both in security terms,
and even more certainly in terms of reliability. But anyway, yes, if
you are really planning this, then a ZSK/KSK split might possibly be
helpful, but not for typical domains.
TIMTOWTDI. :) This could also be useful for situations where you are
anticipating the parent moving to a stronger key, or where the primary
value of the signatures is in an island of trust scenario.
I also wanted to voice my agreement with Joe's response.
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
