This is a discussion on Re: diff between -02 and -03 of forgery-resilience - DNS ; At 14:17 +0100 3/24/08, bert hubert wrote: > http://www.ietf.org/internet-drafts/...ilience-03.txt Comments on -03, "#" in the left means lines from the document. # Measures for making DNS more resilient against forged answers # draft-ietf-dnsext-forgery-resilience-03.txt .... # Abstract # # The current ...
At 14:17 +0100 3/24/08, bert hubert wrote:
Comments on -03, "#" in the left means lines from the document.
# Measures for making DNS more resilient against forged answers
# The current Internet climate poses serious threats to the Domain Name
# System. In the interim period before the DNS protocol can be secured
# more fully, measures can already be taken to harden the DNS to make
# 'spoofing' a recursing nameserver many orders of magnitude harder.
# Even a cryptographically secured DNS benefits from having the ability
# to discard bogus answers quickly, as this potentially saves large
# amounts of computation.
# By describing certain behaviour that has previously not been
# standardised, this document sets out how to make the DNS more
# resilient against accepting incorrect answers. This document updates
# RFC 1034.
I don't like the apologetic tone of the abstract. The more I have seen of
DNSSEC the more I realize it is a mistake to fuse cryptography into the
naming system and protocol - but that's an aside. The upshot is that this
document shouldn't be apologizing for its existence, what it is espousing is
just good, making it harder to stuff answers is nothing but "goodness."
(My) Abstract (suggestion)
This document presents steps that can be taken to make it harder for
a third party to forge a reply to an outstanding query. By making it
harder to predict the values of the fields a client checks to verify that
an incoming response relates to an outstanding query, the chance a
third party can insert an illegitimate answer is lowered.
This document updates portions of RFC 1034 instructing a client to
be more careful when accepting incoming responses.
# 2. Introduction
(First a disclaimer - when it comes to opening sections of documents I get
overly concerned with setting up the problem correctly. I'll try to keep
my nits to a minimum.)
# Additionally, it has recently become possible to acquire SSL/TLS
# certificates with no other confirmation of identity than the ability
# to respond to a verification email sent via SMTP ([RFC2821]) - which
# generally uses DNS for its routing.
The above is the kind of "claim" that really needs to be substantiated
via a reference. I am referring to the "possible to acquire certificates"
statement. As a matter of fact, I don't really believe that it is true,
at least I doubt the value of a certificate backed only by email. I would
suspect there is also a credit card angle to this too.
But I stress, I am not trying to argue this point, but just asking for the
inclusion of a reference to a document that supports the claim.
# 3. Description of DNS spoofing
# When certain steps are taken it is feasible to 'spoof' the current
# deployed majority of caching resolvers with carefully crafted and
# timed DNS packets. Once spoofed, a caching server will repeat the
# data it wrongfully accepted, and make its clients contact the wrong,
# and possibly malicious, servers.
Is 'spoof' the accurate word here? "Forged answers" are the problem, as
well as the practice of "message insertion." I suppose you could say it is
the case that the problem is someone spoofing a server, but the problem
being tacked here is not server authentication but forgery resistance.
# To understand how this process works it is important to know what
# makes a resolver (and more specifically a caching server) accept an
# The following sentence in section 5.3.3 of [RFC1034] presaged the
# present problem:
# The resolver should be highly paranoid in its parsing of responses.
# It should also check that the response matches the query it sent
# using the ID field in the response.
# DNS data is to be accepted by a resolver if and only if:
These rules are not from 5.3.3. of RFC 1034, are they? From the flow here
I thought they were. These are this document's summary, right?
# 1. The question section of the reply packet is equivalent to that of
# a question packet currently waiting for an answer
# 2. The ID field of the reply packet matches that of the question
# 3. The answer comes from the same network address the question was
# sent to
# 4. The answer comes in on the same network address, including port
# number, as the question was sent from
# In general, the first answer matching these four conditions is
"In practice" not "in general." What I want to make clear (and this has
already been in email) is that the "first answer" acceptance is a convenience
and *not necessarily* the best approach.
Perhaps it would illustrative to show a time diagram of how a forged answer
might slip in.
(Packet sniffer attack)
Client v issues query gets gets
DNS forgery ^ true ^
Intermediate v Sees query
(Attacker) Forges response ^
Intended v Sees query
DNS Server Prepares response ^
Client v issues query gets gets
DNS forgery ^ true ^
Intermediate based on prediction
(Attacker) sends response ^
Intended v Sees query
DNS Server Prepares response ^
In both cases, the false one comes first, which is why the current practice
(accept first) is suspect. BTW - the ascii art is "more precise than
accurate," meant as a substitute for sending in the text I'd like to see.
# If a third party succeeds in meeting the four conditions before the
# answer from the authentic answer does so, it is in a position to feed
# a resolver fabricated data. When it does so, we dub it an attacker,
# attempting to spoof in fake data.
# All conditions mentioned above can theoretically be met by a third
# party, with the difficulty being a function of the resolver
# implementation and zone configuration.
"difficulty" of what? I think you mean generating a forgery that is
accepted as genuine.
# 4. Details
Details of what...? Details of attacks or details of defenses?
# The previous paragraph discussed a number of requirements an attacker
# must match in order to spoof in manipulated (or fake) data. This
# section discusses the relative difficulties and how implementation
# defined choices impact the amount of work an attacker has to perform
# to meet said difficulties.
# Some more details can be found in section 2.2 of [RFC3833].
# 4.1. Forcing a question
I think this is what you are saying in this section:
This is one form of what I call a predictive attack. In this, the attacker
predicts that the victim will make a move in response to a stimulus from
the attacker. To the attacker, they first decide what forged answer they want
the victim to accept and then force the victim to ask the question. The
challenge remaining for the attacker is to fill in the fields of the response
that it can't predict before the true response arrives.
Another form of predictive attack is one that takes advantage of the TTL,
the attacker doesn't make the victim ask but guesses when the question will
arise and then attempts to get an accepted forgery.
# 4.3. Matching the ID field
# Additionally, if the target nameserver can be forced into having
# multiple identical questions outstanding, the 'Birthday Attack'
# phenomenon means that any fake data sent by the attacker is matched
# against multiple outstanding questions, significantly raising the
# chance of success. Further details in Section 5.
I ask (again) for a reference to something defining the term "Birthday
Attack." I am not asking for an explanation of it in email, this document
has to have a refernce for the term somewhere.
# 4.4. Matching the source address of the authentic answer
# Generally, this condition requires at most two or three attempts
# before it is matched.
# It should be noted that meeting this condition entails being able to
# transmit packets on behalf of the address of the authoritative
# nameserver. While two Best Current Practice documents ([RFC2827] and
# [RFC3013] specifically) direct Internet access providers to prevent
# their customers from assuming IP addresses that are not assigned to
# them, these recommendations are not universally (nor even widely)
After reading this section, I wonder why the response's source address is
checked at all. If it is soooo easy to forge, what's the use?
# 4.6. Have the answer arrive before the authentic answer
# Once any packet has matched the previous four conditions (plus
# possible additional conditions), no further answers are generally
# This means that the third party has a limited time in which to inject
# its spoofed answer, typically in the order of at most 100ms
# (depending on the network distance to the authentic authoritative
# This time period can be far longer if the authentic authoritative
# nameservers are (briefly) overloaded by queries, perhaps by the
So the summary is - the attacker can either stimulate the victim into asking,
otherwise predict the time of an particular question, or just through dumb
luck, throw packets forging the message ID, question, source and destination
addresses plus a plausible reply (answer/authority/additional section) in less
than 100ms. Our challenge is to make the forgery too difficult to do.
What is unclear is whether the attacks assume that the attacker is
1) next to the victim
2) between the victim and true source (in-line)
3) next to true source
4) no where's near either
5) the attack is targeting a particular domain
6) the attack is targeting the cache of the victim
# 5. Birthday attacks
# The so called birthday paradox implies that a group of 23 people
# suffices to have a more than even chance of having two or more
# members of the group share a birthday.
This time I'll ask the same question again - the number "23" is related to
only 366 days in a year, right? What would the number be if it were 8K or 32K
(which are the numbers presented earlier in the section on message IDs being
just 14 or the full 16 bits)?
# An attacker can benefit from this exact phenomenon if it can force
# the target resolver to have multiple equivalent outstanding questions
# at any one time to the same authoritative server.
This is a new "issue" - whether a querier would have such a situation.
# 6. Accepting only in-zone answers
This is not the next section I expected. The document has taken time to set
up the problem of forgery and I would expect that is time to shift gears into
the steps to be taken to make forgery harder. But instead we branch off into
something completely unrelated.
# Answers from authoritative nameservers often contain information that
# is not part of the zone for which we deem it authoritative. As an
# example, a query for the MX record of a domain might get as its
# answer a mail exchanger in another domain, and additionally the IP
# address of this mail exchanger.
# If accepted uncritically, the resolver stands the chance of accepting
# data from an untrusted source. Care must be taken to only accept
# data if it is known that the originator is authoritative for that
I really don't buy that. If that were true, glue would never work. In
DNS you need to have some level of trust in what you see at first peek
but know to find better info, and ditch bad stuff once you know.
# One very simple way to achieve this is to only accept data if it is
# part of the domain we asked the question for.
I think this is too simplistic to be true. What you want to restrict
acceptance to is data germane to the question. Like the NS records for the
zone purporting to be authoritative for the answer, CNAME/DNAME records
redirection. While I don't like that RFC 1034 included CNAME chasing (in
retrospect a mistake in my book but I realize why it is there), we have it.
(Terminology - we don't ask for data that is "part of a domain.")
# 7. Combined difficulty
# Given a known or static destination port, matching ID field, source
Instead of "destination" use some play on "query/question" "source/origination"
to disambiguate between the query and response source and destination.
# and destination address requires on average in the order of 2 * 2^15
# = 65000 packets, assuming a domain has 2 authoritative nameservers.
64K packets...and it isn't "2 authoritative" but "2 nameserver IP addresses."
Remember, we have anycast and load balancers out there.
# If the window of opportunity available is around 100ms, as assumed
# above, an attacker would need to be able to briefly transmit 650000
# packets/s to have a 50% chance to get spoofed data accepted on the
# first attempt.
# A realistic minimal DNS answer consists of around 80 bytes, including
# IP headers, making the packet rate above correspond to a respectable
# burst of 416Mb/s.
But this attacks just one victim server, not a widespread cache poisoning.
# As of mid-2006, this kind of bandwidth was not common but not scarce
# either, especially among those in a position to control many servers.
# These numbers change when a window of a full second is assumed,
# possibly because the arrival of the authentic answer can be prevented
# by overloading the bonafide authoritative hosts with decoy questions.
# This reduces the needed bandwidth to 42 Mb/s.
I get a little uneasy stretching this without evidence of actual activity
to back it up. For one, I'd have to also have sufficient bandwidth to flood
all authoritative servers (and recall when you deal with anycast, all the
servers that the victim would see, not the attacker) to lengthen the window
of vulnerability. If I was cutting down from 420 to 42 Mb/s for an attack
at a cost of needing n x a high number to shut down other server response,
I don't think it would be worth it - and it would raise alarm bells more
Upshot - the above paragraph seems like hyperbole to me.
# If in addition the attacker is granted more than a single chance and
# allowed up to 60 minutes of work on a domain with a time to live of
Most crooks screw up on the first attempt and get cold feet or caught. This
is why law enforcement works. Again, this paragraph seems more like a scare
statement than the telling of a motivating incident.
# 7.2. Calculation
# The probability of spoofing a resolver is equal to the amount of fake
# packets that arrive within the window of opportunity, divided by the
# size of the problem space.
"Spoofing a resolver"...I think that should be "getting a forged answer
accepted as real. And I don't believe that is the correct probability
measure either. What you have is a measure of what percentage of possible
answers could be confused with the real one. The probability of getting
an answer accepted illegitimately is the probability of getting an acceptable
forgery through in the time allotted.
# When the resolver has 'D' multiple identical outstanding questions,
# each fake packet has a proportionally higher chance of matching any
# of these questions. This assumption only holds for small values of
If they are "identical outstanding questions" then what does "matching
any of these" refer to? I suppose your meaning of identical has some
degrees of freedom in it.
# In symbols, if the probability of being spoofed is denoted as P_s:
# D * F
# P_s = ---------
# N * P * I
P_s = (average number of identical queries x packets sent by attacker) /
(number of nameservers x ports x ids)
I don't know...that makes no real sense to me. You are assuming that the
attacker is trying to get one "point of poisoning" at one server. A point
of poisoning is either one RRset or all the sets at a domain name (via
an "any" response).
(I've been staring at this for a while and can't get it, so I'll move on.)
# 8. Discussion
# The calculations above indicate the relative ease with which DNS data
# can be spoofed. For example, using the formula derived earlier on a
# domain with a 3600 second TTL, an attacker sending 7000 fake answer
# packets/s (a rate of 4.5Mb/s), stands a 10% chance of spoofing a
# record in the first 24 hours, which rises to 50% after a week.
The problem I have is that the "relative ease" is only presented via a
calculation that I have a hard time following. Is this kind of attack
really happening? Is there any evidence to demonstrate (as opposed to
calculate) the relative ease?
# 9. Countermeasures
# o Question name (compared case-insensitively)
# o Question class and type
Keep in mind that the above does not (yet) apply to AXFR.
# Resolver implementations MUST have the ability to:
Why are these "MUST"s and not "RECOMMEND"ations?
Is this needed for interoperability?
# If a resolver sends out multiple equivalent questions to any
# authoritative server, before receiving an answer, all MUST have
# identical ID, source address and source port.
Then you are fixing D:=1?
# Resolvers SHOULD favour authoritative nameservers with which a trust
# relation has been established; Stub-resolvers SHOULD be able to use
# TSIG ([RFC2845]) or IPSEC ([RFC2401]) when communicating with their
# recursive resolver.
Or SIG(0) or some other message/datagram verification scheme...
# In case a cryptographic verification of answer validity is available,
# resolver implementations MAY waive above rules, and rely on this
# guarantee instead.
Why? What if I sign something, distribute it and then discover I want to
"revoke" it. It is possible someone could replay the shoulda-been-revoked
data to drown out the good replacement data. Or what if I yank off DNSSEC
because of an error and want to return to unsigned?
Cryptography is not a panacea.
# 10. Security Considerations
No IANA Considerations?
Edward Lewis +1-571-434-5468
Never confuse activity with progress. Activity pays more.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.