Subject: Do any DNSEXT participants care about TAK rollover security?

From: Thierry Moreau <[email-masked]>
Date: Sat, 08 Jul 2006 14:35:43 -0400

Dear DNSEXT wg participants:

Trust anchor Key Rollover (TAK) for DNSSEC is part of an IT security 
scheme. It must also by an interoperability specifications that is 
deeply influenced by the installed base of DNS technology.

DNSEXT came up with draft-ietf-dnsext-rollover-requirements-02 as the 
current definition of requirements for a TAK rollover solution, but it 
is almost by accident that the requirement 5.13 was added in the draft 
to reflect the need for TAK rollover security, and even the active 
document editor (Suresh Krishnaswamy) seems to have difficulty with it: 
in http://www.dnssec-tools.org/docs/trust-anchor-comparison-v02.htm, he 
comments about requirement 5.13 writing "May be a policy issue (which 
algorithm to allow etc). How does one define degraded trustworthiness?" 
And then he abstain from applying requirement 5.13 to alternatives in an 
otherwise meticulous and interesting comparison chart.

It all boils down to whether TAK rollover solutions are evaluated with 
or without a properly formulated security criteria. I came to the 
conclusion that the DNSEXT wg focuses on interoperability and DNS 
installed base compatibility, almost exclusively.  (The draft 
draft-moreau-dnsext-tak-req-00 contains contributions in this direction, 
that were set aside completely.)

Thus, the question is whether any DNSEXT participants care about 
security. I suggest that those who do, if any, should speak up now.

Incidentally, outside of the IETF, there might be some voices calling 
for the criticalness of security in the DNSSEC overall solution (e.g. 
the presentation made by Maria Zitkova about DNSSEC deployment in the 
.aero sponsored TLD for the airline industry, 
http://www.icann.org/meetings/marrakech/captioning-DNSSEC-28jun06.htm).

So, I'm in Montreal next week during the IETF 66 meeting, but I'm still 
skeptical about DNSEXT ability to address the automated TAK rollover 
issue in a productive way. In any event, enjoy your stay in this 
marvelous city at the right time of the year!

Regards,

-- 

- 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: [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Scott Rose" <[email-masked]>
Date: Tue, 11 Jul 2006 14:00:33 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Thierry Moreau
>

FWIW, I care.  I don't know if TAK is the best solution for deployment
however.  My main concern is unfortunately more administrative than
technical.  It mainly concerns the pre-generation of keys and the dead
storage.

I can imagine a zone could generate all the operational keys it believes it
needs, but that means zone admins have to be good at predicting the future -
both key sizes and changes in algorithms.  Or a worst case scenario - a
weakness is found in either a key algorithm or the MASH algorithm used with
the scheme.

In these cases, it seems the only option is to restart the process from the
beginning and have every validator obtain the new information (keys, hashes,
etc).  Much like an emergency rollover, but any validator off line for an
extended period of time may miss this notice and loose track of the new
rollover list.

The concept of dead storage is good, but adds additional complexity to any
zone that changes administrative entities (say, a contractor operating the
zone for one year, then losing the contract to another entity).  Note:  I
realize this isn't a technical comment, but for some zones (the root and
tld's), technical problems are sometimes secondary to administrative ones.

I realize that these concerns may be FUD (I haven't thought it all through),
but these are the drawbacks I saw that other proposals lacked.  If I am
totally off base (which is possible), please elaborate.

Scott

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 11 Jul 2006 22:44:09 -0400

Scott Rose wrote:
> however.

I guess (from the remaining of message contents) you mean TAKREM (not TAK).

>          My main concern is unfortunately more administrative than

Being good at predicting future key sizes at once? Indeed. Other 
alternatives require being good at selecting key sizes on an on-going basis.

A weakeness in key algorithm (i.e. DNSSEC signature algorithm -- RSA in 
practice)? Either the weakness is a total collapse and any DNSSEC has to 
be re-primed, or the weakness is partial in that a powerful adversary 
takes months instead of decades to factorize a public key modulus in 
which case it can be shown that MASH usage scenario is immune (the 
adversary does not get the MASH modulus mush before the new public key 
operational phase).

If MASH itself breaks in the TAKREM usage scenario, it is likely to be 
through advances in large integer factorization, in which case RSA 
breaks and it boils down to the previous paragraph. Theoretical 
foundation for the x^2 mod N (also in Rabin/Williams) has been revisited 
by Dan Boneh.

> extended period of time may miss this notice and loose track of the new

If any system is off-line while the rest of the world is recovering from 
a serious breach in RSA or any any public key cryptography based on 
integer factorization, it should be upgraded with appropriate software 
patches anyway (including DNS resolver secure configuration elements).

> tld's), technical problems are sometimes secondary to administrative ones.

Did you ever notice that daily activities are impeded by locks, 
passowrds, security clearances, document distribution authorizations, 
and the like. DNSSEC essentially puts data integrity controls in the DNS 
distributed database contents management - intrinsically a data 
manipulation impeding proposal. Basically, you can't have millions of 
resolvers trusting a trust anchor for organization A on a sound basis 
and then suddenly believing that organization A' becomes as genuine and 
trusted as A was (at least, this was not a requirement).

Actually agreed-upon transfer of trust anchor control from A to A' is 
conveniently supported by TAKREM as a controlled transfer of dead 
storage contents. Disruptive (e.g. litigious) transfer of trust anchor 
control can hardly be supported by any secure trust anchor key 
management scheme.

> but these are the drawbacks I saw that other proposals lacked.

Perhaps the other proposals either were silent about some of these 
issues, and implicitly impacted in a similar way.

>   If I am

My original post was about the approact to requirements definition, so 
you and I might be somehow off-topic. Otherwise, your observations about 
the TAKREM scheme appears relevant to me. Thanks for sharing them.

Regards,

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900