transaction security in the last mile

[Paul Vixie <vixie@isc.org>]

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

whereas XQID or anything like it would either rely on EDNS and would have
to fall back to less security if an attacker could spoof a non-EDNS reply,
or would bypass EDNS and do its own feature negotiation where the fallback
would be something like "repeat the whole transaction several times using
newly randomized QID and UDP.PORT (and maybe QNAME 0x20) each time", and

whereas TSIG relies on a pre-shared secret key involving out of band key
exchange (such as "sneaker-net") which is expected to scale badly in large
installations and be useless in ISP or ASP situations, and

whereas GSS-TSIG relies on a working GSS (think kerberos 5) installation
that encompasses both RDNS and its client stubs, which is known to be rare
in the world and never present in ISP or ASP situations, and

whereas SIG(0) (or is it RRSIG(0) now?) relies on a working Secure DNS
system containing a TKEY RR at the RDNS's hostname, which has proven
elusive due to the extreme duration of Secure DNS's development and the
lack of general interest among anybody other than technology vendors and a
few CCTLDs, and

whereas BCP38 deployment has utterly stalled in recent years and is likely
to never be complete enough to make IP source addresses generally repudiable
and even if we somehow did reach universal BCP38 deployment the sense of
security this would give us would be false since backsliding could happen
at any instant and would be mostly transparent at first, and

whereas we have now randomized everything we can (QID, UDP port, QNAME 0x20)
and this gives us only stant statistical protection against DNS forgeries
involving injection of packets having spoofed IP source addresses, yet we
have no cause for confidence in our continued safety in a world full of
smart ambitious security researchers (some good, many evil) whose computers
and networks get faster every year, ...

..

.. i think it's time for a new debate on the nature of the relationship
between the stub and the RDNS.  i wish to leave aside the relationship
between the RDNS and ADNS, since these are far more numerous, and the kinds
of negotiations or state that are practical in the stub/RDNS relationship
might be completely impractical in the RDNS/ADNS relationship.  in this
discussion, a "stub" refers to either an initiator with no DNS-layer cache,
or to an RDNS configured to use a "forwarder".  in both cases, the number
of relationships a given initiator is in, or that a given responder is in,
is finite and manageable.

here are some possible roads, and the reasons they're each hard to follow.

1. always use tcp.  with random initial sequence numbers now the standard,
we generally consider tcp sessions unspoofable unless the ISO-L2 is
insecure near either endpoint, or unless the routing layer is attacked.
for many stub/RDNS deployments, the number of stubs simultaneously doing
DNS will be lower than the number of tcp protocol control blocks or socket
descriptors available on the RDNS host and application.  however, in many
ISP deployments there can be millions or tens of millions of stubs for
every RDNS, and not even anycasting or load balancing will make that fit,
so we'd be contemplating a very short (subsecond) timeout for idle DNS TCP
sessions, which calls for some modelling to find out what the packet count
and RTT cost would be for the average stub in that environment.  also, stubs
would have to funnel their queries through shared local protocol agents,
and these agents may become a new target for injection attackers.

2. diffie-hellman.  it is possible, with the exchange of several random
numbers used as encryption and decryption keys, for two endpoints with no
shared secret to establish a trust relationship.  this takes measureable
time and effort, so the existence of this trust relationship is usually
remembered by the endpoints, creating "session state" which can be used to
generate nonces or shared keys.  RFC 2930 is an example of such a method,
whereby the TKEY meta-RR is used to carry keying information for the TSIG
meta-RR.  no known large deployment currently uses TKEY to create trust and
then TSIG to protect query transactions, so while this approach may be
practical, its error modes remain unmeasured.  because such relationships
are not held in protocol control blocks and/or socket descriptors, it may
be possible for an RDNS to relate to millions of stubs in this way.
however, the stubs will probably require additional processes or files to
hold the trust state for each RDNS, and this state may become a new target
for injection attackers.  there's also a lurking downgrade attack involving
spoofed ICMP-Port-Unreach, since the D-H and key data won't be in the first
64 octets of the payload, which ICMP uses as a nonce.

3. IPv6 multiplicity.  in IPv6, most LANs will have 64-bit netmasks, leaving
64 bits for host addressing, which are expected to be sparsely allocated.
it is possible that a stub host could allocate a few dozen addresses, and
choose one at random as a source for requests to RDNS.  there is a tension
between having enough source addresses to matter from a security nonce point
of view, vs. having too many to manage in the exit gateways who must maintain
ARP state for each address, mapping back to each stub's MAC address.  it's
unlikely that the number of additional random bits we need can be accomodated
by this layer of the IPv6 architecture, and furthermore, IPv6 isn't here yet.

4. new port.  most of the constraints are due to backward compatibility
problems, and if we simply allocate a new UDP port, other than 53, then we
can make new rules.  it's easy to design a completely stateless replacement
for stub DNS that involves 128-bit random nonces.  while there would be some
delay while IETF debates which part of the kitchen sink to leave in or remove,
it's safe to say that there would be no authority or additional data section,
no RD bit, very few options in general, and that we could avoid having this
turn into a replacement for the current global DNS protocol used for the
RDNS/ADNS relationship.  what's less clear is how the fallback strategy would
be secure, since a "new-stub" would have to fall back to standard UDP/53 if
it could not get an answer on the new UDP port from any of its RDNS's.  could
we put the nonce near the front of the UDP payload so that ICMP-PortUnreach
(which uses the first 64 bytes of the datagram) would be hard enough to forge
that we could confidently assume that there was never a downgrade attack?

i know that's a paltry list.  others here should be able to think of more
alternatives.  i'd like to avoid a re-debate over XQID, though, so if that's
your position i ask that you hold off on elucidating it here to let this topic
be explored on the basis that XQID, TSIG, SIG(0), and BCP38 are nonstarters.
i'd really like to know whether always-tcp, diffie-hellman, ipv6-multiplicity,
or new-port are practical or not, and whether there are other ideas lurking.

of the ideas above, i dislike the new-port idea the least, and that's very
depressing, since from a deployment perspective, SIG(0) would be about the
same total cost.  (the largest part of the cost is touching all or most of
the stubs, not in the specific complexities added by that touch.)

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


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