Comments on draft-ietf-dnsext-forgery-resilience-01.txt

[Florian Weimer <fw@deneb.enyo.de>]

Here are a couple of comments, I hope you'll find them useful.

| 1.1. Definitions

| Attacker: malicious third party.

Attackers aren't a third party anymore.  It's important to protect
against malicious activities from your own, legitimate client base, too
(and this is even mentioned in the draft).

| 2.  Introduction

| Additionally, it has recently become possible to acquire SSL
| 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.
| 
| In other words, any party that (temporarily) controls the Domain Name
| System is in a position to reroute most kinds of Internet
| transactions, including the verification steps in acquiring an SSL
| certificate for a domain.  This in turn means that even transactions
| protected by SSL could be diverted.

SSL has been superseded by TLS.  Domain-validated certs aren't the only
problem with the browser PKI.  IIRC, there have been studies that show
that most users accept self-signed certificates, so secure web
transactions mostly hinge on DNS and BGP integrity.  (I should be able
to dig up the details, if you are interested.)


| 3.  Description of DNS spoofing

|    DNS data is accepted by a resolver if and only if:
| 
|    1.  The question section of the reply packet is identical to that of
|        a question packet currently waiting for an answer

Exception: error responses (see the previous thread,
<http://www.ops.ietf.org/lists/namedroppers/namedroppers.2007/msg00686.html>)

|    5.  It is the first answer to match the previous four conditions.

This may be costly to enforce in a highly paralleled server, I guess.

| 4.1.  Matching the question

| The time to live of the 'target domain' determines how often a window
| of opportunity is available, which implies that a short TTL makes
| spoofing far more viable.

I no longer think this is true.  I haven't tested my hypothesis in a
lab, but I strongly believe that if you can spoof a response when a
record set expires, you can also spoof at a time of your choice (i.e.,
without having to wait for expiration).

Would this be a significant problem?

| 4.4.  Matching the destination address of the authentic answer

|    It should be noted that a firewall will not prevent the matching of
|    this address, as it will accept answers that (appear) to come from
|    the correct address, offering no additional security.

This should read "firewall with no DNS-specific logic".

| 5.  Birthday attacks

|   A curious mathematical phenomenon means that a group of 22 people
|   suffices to have a more than even chance at having two or more
|   members of the group share a birthday.

IIRC, the magic number is 23.

| 7.2.  Calculation

| Finally, to calculate the combined chance 'P_cs' of spoofing over a
| chosen time period 'T', it should be realised that the attacker has a
| new window of opportunity each time the TTL 'TTL' of the target
| domain expires.  This means that the number of attempts 'A' is equal
| to 'T / TTL'.

As mentioned above, I don't think that long TTLs offer any kind of
protection.

| 9.  Countermeasures

If a resolver detects that it's facing some kind of spoofing attack, it
MAY try to get additional validation by using TCP instead of UDP for
queries.  As a result, authoritative servers SHOULD provide TCP service
unconditionally.  (This requires an update of RFC 1123.)

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