Re: Last Call: Root Name Server Operational Requirements to BCP

["D. J. Bernstein" <djb@cr.yp.to>]

I continue to object to opreq on security grounds.

The following table summarizes the security situation from an attacker's
perspective (assuming unpredictable query ports and IDs---true for many
caches now, and presumably almost all caches in a few years):

   DNS                      Trivial to break from anywhere.
   DNS+opreq                Trivial to break from anywhere.
   DNS+opreq+inzone         Need to sniff or send billions of forgeries.
   DNS+dnssec               Need to subvert one of the signers.
   DNS+dnssec+opreq         Need to subvert one of the signers.
   DNS+dnssec+opreq+inzone  Need to subvert one of the signers.

Explanation of the symbols:

   * opreq: the security practices required in opreq-03 and opreq-04,
     such as avoiding insecure software on central DNS servers;

   * inzone: the very low-cost, and fairly common, practice of using
     in-zone _names_ for NS records;

   * dnssec: the very high-cost, and currently mythical, practice of
     creating and verifying IANA+NSI+... signatures.

The opreq authors appear to believe that opreq by itself adds security.
That belief is incorrect, as my bugtraq message demonstrates.

On the other hand, opreq+inzone would drastically increase the
attacker's expense, at the trivial cost of changing a few NS names.

---Dan