[dnssec-deployment] signing of the root - version 2
steve at shinkuro.com
Fri Oct 21 10:11:42 EDT 2005
You make a good point that the technology, policy and security
aspects all have to fit together. As we discussed on the call, a
prerequisite for considering technology is a satisfactory IPR
situation. Have you given some thought to filing a statement with
the IETF re TAKREM that is consistent with the other IPR the IETF
generally finds acceptable? It would be a big help.
steve at shinkuro.com
On Oct 21, 2005, at 10:33 AM, Thierry Moreau wrote:
> Dear all:
> I am half surprised to see "The working group expressed
> agreement with the proposed answer [to Q1 about
> technology and practices for root KSK generation]"
> while I proposed a KSK generation procedure compatible
> with the TAKREM proposal (Mike St-Johns might do the
> same since the timers-based rollover mechanism has
> implications for root key management, e.g. 2 or more
> independently managed KSKs).
> I think there is an issue of technology selection vs
> security scheme vs policy issues. If during week 1, the
> wg selects technology and then on week n+1 the wg
> address the policy issues, it is deemed to fail (i.e.
> lack of security schemes that glues technology to
> During the October 19 telephone call, someone mentioned
> that liability issues are going to hit the root
> operations, sooner or later. The DNS root is not unlike
> a global PKI certification authority, and the X.509
> technology has been essentially spoiled, mostly on the
> liability/policy issues for global certification
> Don't read the above as critique for interim technology
> deployment, e.g. as a testbed with a required
> disclaimer on the root KSK reliability, or the
> pragmatic DLV approach suggested by Paul Vixie.
> I merely call the attention to a structured approach:
> can the root key management questionnaire be a step
> towards better technology/policy integration? (the
> answer appears to be yes in the case of Q.2 and Q.3
> about key sizes)
> may the group state some rollover requirements that
> are missing (the DNSOP activity "Submit
> Requirements for Automated Key Rollover in DNSsec
> to IESG for Informational" is one year late and the
> is expired)?
> specifically, may the group acknowledge that root
> key management and trust anchor rollover are bound
> by a security scheme, and addressing policy in
> isolation is counter-productive.
> Once DNSSEC starts to be deployed, these issues will be
> questioned and scrutinized by the cryptographic
> community which appears delighted to pinpoint security
> design flaws after the fact (and perhaps by privacy
> activists, which becomes part of the noise that DNSSEC
> will be exposed to). So it is perhaps better to pick up
> the ball now from DNSOP ...
> Turning into productive tossing of ideas:
> (A) About key sizes, there seems to be a question
> whether size(ZSK)=size(KSK) or not. Should this be
> extended to TLD key sizes, so that a resolver
> validation sees no "weak link" in the chain of
> signatures, i.e. a shorter TLD key size? If yes, then
> the current NIST recommendations for key sizes (, NIST
> Special Publication 800-57, section 5.6.1) mandates the
> switch from SHA-1 to SHA-224 or more for DS record
> (B) Now that the TAKREM proposal is in the form of
> Internet Draft, is it useful to revisit my answers to
> questions that I submitted on October 6 (mainly Q.1 and
> (C) See below for a specific example of a mating point
> between liability/policy and security scheme.
> An historic precedent for rule-making strategy for
> security strength vs operational efficiency dilemma. In
> the United States "Uniform Commercial Code" article 4a
> dealing with authentication of electronic funds
> transfers for commercial customers, the notion
> "Commercially acceptable security procedure" that can
> be waived by the customer:
> U.C.C. - Article 4a - Funds Transfers
> Part 2. Issue and Acceptance of Payment Order
> 4A-202. Authorized and Verified Payment Orders.
> (a) ...
> (b) ...
> (c) Commercial reasonableness of a security
> procedure is a question of [...]. A security
> procedure is deemed to be commercially reasonable
> if (i) the security procedure was chosen by the
> customer after the bank offered, and the customer
> refused, a security procedure that was commercially
> reasonable for that customer, and (ii) the customer
> expressly agreed in writing to be bound by any
> payment order, whether or not authorized, issued in
> its name and accepted by the bank in compliance
> with the security procedure chosen by the customer.
> (d) ...
> (e) ...
> (f) ...
> The official commentary on this partially read as
> "Sometimes an informed customer refuses a security
> procedure that is commercially reasonable [...] and
> insists on using a higher-risk procedure because it
> is more convenient or cheaper. In that case [...],
> the customer has voluntarily assumed the risk of
> failure of the procedure and cannot shift the loss
> to the bank."
> The relevant fact is that this little segment of
> statutory provision (covering both technology selection
> criteria and liability/policy) is THE accepted base for
> electronic funds transfers (with a worldwide trend-
> setting influence, through UNCITRAL Model Law on
> International Credit Transfers).
> An equivalent strategy can be used to limit the
> liability of the DNSSEC root management IF a trust
> anchor key distribution and/or rollover mechanism
> (analogous to "commercially reasonable") is offered to
> zone managers, along with the option to rely on the DNS
> root as a "higher-risk procedure," thus limiting the
> root management liability because an alternative to
> root reliance has been offered. (I assume that root
> liability is devoted to zone managers, not resolvers
> having no contractual relationship to a zone's parent
> Hope it helps,
> - Thierry Moreau
> CONNOTECH Experts-conseils inc.
> 9130 Place de Montgolfier
> Montreal, Qc
> Canada H2M 2A1
> Tel.: (514)385-5691
> Fax: (514)385-5900
> web site: http://www.connotech.com
> e-mail: thierry.moreau at connotech.com
> This message is sent to you because you are subscribed to
> the mailing list <dnssec-deployment at shinkuro.com>.
> To unsubscribe, E-mail to: <dnssec-deployment-off at shinkuro.com>
> A public archive is available here: <http://mail.shinkuro.com:8100/
More information about the Dnssec-deployment