dns hop by hop transaction security for queries

[Paul Vixie <paul@vix.com>]

i have learned quite a lot about what's possible and how things work from
the recent thread "transaction security in the last mile" and i now have
a proposal to float.  i'm sorry i won't be in dublin to discuss this in
the hallways, but hopefully discussions will occur and i will hear about
them through this mailing list.

problem statement: BCP38 can never be nonfalsifiably universally deployed,
so any given IP datagram's source address must always remain suspect.  the
basic DNS query transaction uses two-packet UDP (request and response), and
each side (initiator and responder) is vulnerable to spoofed-source attacks,
where the initiator can be poisoned by untrue DNS data sent by an attacker
and the responder can be made to amplify a DDoS against innocent parties.

background:

DNSSEC offers both end to end data authenticity through its DNSKEY, RRSIG,
and NSEC{3} records, and stub/RDNS data authenticity through its {RR}SIG(0)
protocol.  deployment of DNSSEC in the root and COM zones is stalled for
political and economic reasons (respectively), and there is no path forward
involving private right of action by interested subsets of the community.
(leaving aside DLV, which is such a way, but is shrouded in controversy.)

GSS-TSIG offers stub/RDNS transaction authenticity but requires that the
stub and RDNS both be inside a fully functioning Kerberos realm, which is
not practical outside the enterprise (for example, in ISPs or hotel rooms.)

TSIG offers stub/RDNS transaction authenticity but requires that a shared
secret be installed by some out of band method, which is impractical for
query relationships due to the number of stub/RDNS relationships.  TSIG is
very successful for zone transfer and update relationships, which are fewer.

TKEY offers a way to establish a TSIG shared secret where the only starting
configuration data is that the initiator must know the responder's IP
address (which is true in the case of stubs and their RDNS'.)

DHCP could be made to carry an additional configuration element, "TSIG key",
to be associated with a given responder.  this follows from the fact that if
DHCP is spoofable, then the entire DHCP response is suspect, including the
elements for "RDNS IP".  as long as responder-side TSIGs were kept longer
than the DHCP lease time, this would work.  however, it's known that many
DNS initiators do not use DHCP at all, so this solution would be incomplete.

IPSEC and VPN's in general can be used to protect stub/RDNS transactions at
a higher configuration cost which is unjustifiable for the average DNS client
and which generally requires greater than average technical expertise.

be it noted, ICMP is also subject to spoofed-source attacks, and any UDP
flow even of short two-packet duration can be interrupted and made to fail.
this is true but to a lesser extent for TCP flows.

parameters:

a solution here would be opportunistic and pairwise deployable, requiring
no flag days; it would require no new technical expertise for end users; it
would have only graceful failure modes; it would not be subject to downgrade
attacks; and ideally, it would require no new protocol development work.

proposal:

stubs, and caching forwarding servers, when acting as initiators, should
use TKEY over TCP/53 to try to set up a shared secret with their
responders.  if successful, this secret should be used for UDP/53 queries
to that responder.  if TKEY over TCP/53 is successful for some responders
but not others, then the successful ones will be used exclusively.  if at
least one TSIG signed query transaction succeeds to a responder, and then
later transactions fail with TSIG errors (BADSIG) then TKEY over TCP/53
should be repeated.  if no TSIG signed query ever succeeds, then after some
small number of retries, the TKEY should be discarded and no longer used.
in cases where there is TKEY over TCP/53 fails, or where a TKEY was
acquired but then discarded, then TSIG must not be used on transactions to
that responder.

discussion:

there would be no protocol changes and no API changes.  this uses only DNS
protocol elements which are already defined, requiring only implementation
and deployment.  there is no reason for an API change since applications
are not expected to behave differently based on the degree of certainty in
the stub/RDNS transaction.

this could be argued as applicable to RDNS/ADNS relationships as well,
perhaps even when the RDNS contains a DNSSEC validator, but whereas the
number of TKEY over TCP/53 transactions is manageable, the amount of state
that both RDNS and ADNS would have to store and access, may not be.

initiators who implement the logic described in this proposal may have an
additional configuration knob, "TKEY and TSIG must succeed", either on a
per-responder basis, or globally.  this would disable fallback to UDP/53
and would render that endsystem unusable if the last mile DNS is not secure.
note that initiators with that knob would experience "flag day" behaviour,
rather than the softer opportunistic behaviour experienced otherwise.

that's all.

-- 
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/>