Scott Rose wrote:
The original RFC 4641 came out before the update-timers draft became an
RFC. The revision would need to incorporate that as well as the
improved crypto stuff.
For the record, the DNSSEC deployment in .org has been approved by the
ICANN board
http://www.icann.org/minutes/resolutions-26jun08.htm#_Toc76113176
while the DNSSEC experts at PIR (.org registry manager) stated publicly
[quote] Concerned about “stopping DNSSEC” if needed
• Proposes implementing RFC 5011
• In our opinion – this does not solve the problem, since a complete key
set compromise would still need a “full stop” [/quote]
Ref: http://par.icann.org/files/paris/RaadDNSSEC.pdf on slide 4.
This is at least some feedback from experts with direct operational
accountability for non-root-zone KSK management.
Personally, I think TA management guidelines for non-root-zone
management is inefficient use of standards drafting resources. Instead,
simply insist that the parent zone should support DNSSEC at the earliest
opportunity - NSEC3 opt-out is available for large parent zones.
The discussions about TA repositories are addressing the same issue (IOT
manager, the poor little orphan of DNSSEC) on a different approach. I
guess DNSOP might explicitly exclude the registration of KSKs in TA
repositories from the scope of an RFC4641 revision effort.
Best luck to those who will contribute to this document drafting effort,
if any!
--
- Thierry Moreau
So yes, I would support this effort.
Scott
Paul Hoffman wrote:
Greetings. I had a brief discussion with Olaf Kolkman about some
deficiencies in RFC 4641, and he agreed to revise the document if the
WG is interested. This message is to start gauging interest in that task.
I started reading RFC 4641 when I was on the panel at ICANN that
reviewed PIR's proposal to start signing .org. I am not a DNSSEC
operator (yet), so I came to the document with a novice's eyes. There
are three areas which I found problematic:
- The cryptography that got added after WG LC is flawed. The
calculations of appropriate key sizes starts with solid numbers
(quoted from an RFC that Hilarie Orman and I wrote) and then quick
falls into handwaving. It can be greatly simplified.
- The discussion of key rollover times has no justification for the
times chosen. There is no discussion of the attacks that the rollover
is trying to mitigate. Such a discussion would help a zone decide that
zone's rollover policies.
- It is not clear when the document is talking about publishing keys
as trust anchors and when it is talking about publishing them in a
signed parent zone. These two scenarios are vastly different,
particularly with respect to key rollover.
Olaf agreed that there may be more operational input from people who
are currently deploying DNSSEC, and that this document might be ripe
for a renewal even though it is less than two years old. How do people
in the WG feel about this?
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
