Subject: Re: [DNSOP] Priming query transport selection

From: Alfred Hönes <[email-masked]>
Date: Wed, 13 Jan 2010 21:58:32 +0100 (MEZ)

I apologize for cross-posting due to topical overlap.
Please confine follow-up messages to the appropriate list.

In the message to DNSOP regarding draft-ietf-dnsop-resolver-priming-02
archived at
  <http://www.IETF.ORG/mail-archive/web/dnsop/current/msg07843.html>,
Olafur Gudmundsson scratched at a topic of interest to namedroppers
as well; he wrote:

>  ...
>
> Background:
> 26 signed glue records will require about 5K answer if each RRSet is
> signed by a single 1024 bit RSA key.
> This will never fit into an ENDS0 answer as number of implementations
> have 4096 byte hard limit on answer size.

Did you read the News these days?

An international team lead by the BSI (the "German NSA") and others
has solved the RSA-768 challenge, and experts reportedly expect, due
to significant progresses, that RSA-1024 will be solved in a rather
short time, likely by the end of this year or so!

This means that we should immediately plan operationally for
widespread use of 2048-bit RSA keys in the "near" future.

> As of today all the root servers instances that my host reached
> answered a TCP query.
>
> Proposed replacement text:
>
>|2.1.  Parameters of a Priming Query
>|
>|  A priming query MUST use a QNAME of "." and a QTYPE of NS, QCLASS
>|  of IN, with RD bit set to 0, the source port of the query should
>|  be randomly selected [RFC5452].
>|
>|  A DNSSEC aware resolver SHOULD sent the priming query over TCP.
>|  If TCP is refused a different server SHOULD be tried, after 3 tries
>|  the resolver SHOULD fall back on UDP.
>|
>|  A DNSSEC ignorant but EDNS0 capable, resolver SHOULD issue the
>|  priming query over UDP, ENDS0 option MUST be included with buffer
>|  size of 1220 or larger.  If the UDP query times out TCP SHOULD be
>|  tried.
>|
>|  An EDNS0 ignorant resolver MUST issue the priming query over UDP.
>
> ...

I therefore support the proposal suggested by Olafur:

Recommend that <DNSSEC aware resolvers> SHOULD issue priming queries
immediately over TCP, and not waste time and bandwidth with an
initial query over UDP (that will be truncated with certainty).
Even UDP with EDNS0 and 4k message size limit (which most likely
will need fragmentation and have trouble with firewalls) will not
provide a workable solution for a reasonable life time (of RFCs
and deployed equipment) and should only be tried as a fallback.

Those not liking DNS over TCP might wish to convince the IEEE to
quickly double the Ethernet frame size in the interim (in deployed
networks as well, of course!) and the IETF to bump the IPv4
512-byte UDP margin.   :-)

Additionally:
++++++++++++

Work on the use of Elliptic Curve Signatures with DNSSEC urgently
needs to be resumed *now* (in DNSEXT).

EC keys and signatures will roughly be shorter than RSA keys and
signatures by a *factor* of 4..8, for comparable levels of security.

Kind regards,
  Alfred.

P.S:  Olafur:   s/ENDS0/EDNS0/g  !   :-)
                   ^^    ^^
      [ BTW, one of my favorite personal typos, as well! ]

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Jim Reid <[email-masked]>
Date: Thu, 14 Jan 2010 10:28:39 +0000

> short time, likely by the end of this year or so!

Hmmm. The paper by Klienjung et al (http://eprint.iacr.org/ 
2010/006.pdf) said it took ~2000 Opteron-years and ~2.5 years of  
elapsed time to crack RSA768. So if you change keys every month or  
two, there's not much to worry about.... BTW the authors of that paper  
said they don't expect 1024-bit RSA to be factored for another 5-10  
years with comparable resources to their RSA768 efforts unless  
factoring algorithms improve a lot.

> widespread use of 2048-bit RSA keys in the "near" future.

True. Some of us deployed 2048-bit RSA keys in 2007. Perhaps your  
friends at BSI might like to crack the KSK or ZSK for rfc1035.se? :-)

---

From: Danny Mayer <[email-masked]>
Date: Sun, 24 Jan 2010 00:38:19 -0500

>> |  An EDNS0 ignorant resolver MUST issue the priming query over UDP.

I'm not sure I understand the point to this part. Since this is a draft
and you would be talking about the next versions of resolvers that would
be expect to support this (as opposed to existing ones) why would you
expect there to be any future resolver ignorant of DNSSEC? Aren't we
trying to make DNSSEC mandatory for future resolvers?

Danny

---

From: Alfred Hönes <[email-masked]>
Date: Sun, 24 Jan 2010 17:23:24 +0100 (MEZ)

Danny Mayer wrote, in a response sent to me, referring to

> trying to make DNSSEC mandatory for future resolvers?

Danny,
Please note that the quoted block of text wasn't mine, so maybe your
message ought to have be addressed primarily to its author.
But never mind.  It has arrived there and on the lists.

The primary goals of my posting were to point out that:

  - limiting the recommended priming query discussion and advice
    in teh Priming Query draft by a perspective on 1024-bit RSA keys
    and signatures is too narrow-headed if the advice shall last
    for more than a very small couple of years, and

  - with respect to message size issues and efficiency, DNSEXT
    should resume work on ECC keys and signatures for DNSSEC ASAP.

Regarding your argument agaibst Olafur's suggested text, I fear
there will be lots of resolvers for many years that cannot reasonably
be expected to be DNSSEC aware, i.e. performing DNSSEC validation.

I do not want to touch on policy issues -- whether CPE and end
systems are in a better place for providing useful trust by
performing DNSSEC validation than typical large-scale caching
resolvers provided and maintained by ISPs.

However:
DNSSEC is a huge code addition, in particular for embedded TCP/IP
implementations; the proliferation of signature algorithms we are
starting to admit will make things even more complicated.
In contrast, EDNS0 is a rather tiny addition providing general
utility and it indeed really should be supported by such
implementations.
Therefore, I believe that we should give valid advice for such
small-scale implementions as well -- they'll depend on working
priming queries in any case.

As pointed out by other folks in another current thread on DNSOP,
BCP documents should not restrict the advice they are giving to a
single mainstream scenario when the topic is more general in
nature, but better cover various important scenarios.
Thus, I indeed recommend to keep appropriate advice for DNSSEC
unaware resolvers in the Priming Query draft.

Kind regards,
  Alfred.

--

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 25 Jan 2010 21:32:13 -0500

>trying to make DNSSEC mandatory for future resolvers?

While some of us hope all resolvers will support DNSSEC at some point 
in the future,
there are resolvers that never will.
The paragraph as I tried to frame it is to not place onerous burden 
on the system,
if a Resolver has no intention of validating anything it should 
"consider itself as
DNSSEC ignorant".

         Olafur