[dnssec-deployment] signing of the root - version 2

Fri Oct 21 10:11:42 EDT 2005

Thierry,

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

Steve Crocker
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
> policy).
>
> 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
> authorities.
>
> 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
>      draft
>      draft-ietf-dnsop-key-rollover-requirements-02.txt
>      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
> construction.
>
> (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
> Q.8)?
>
> (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
> manager.)
>
> 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/ 
> Lists/dnssec-deployment/>
>
>