On Aug 22, 2008, at 1:33 PM, Nicholas Weaver wrote:
> But, see the above, even with the fully secured NAME->IP mapping, you
> are still in the exact same position in your attack scenario:
> completely h0zed unless the user's actual protocol supports end-to-end
> crypto right.

On reflection, I think that I am arguing about the wrong thing.
You're right that DNSSEC doesn't stop a MitM attack. A smart
attacker would allow DNS to flow freely, and attack elsewhere, if they
controlled your link to the rest of the world. To protect against
this would require much more careful use of SSL than is common at
present, and DNSSEC would not help.

However, there's a case that you haven't really covered in your
analysis. That's the case where the attacker gains control of the
local cache. They don't have control of the path, but because they
control the cache, they can convince you to send packets to them
instead of to the correct destination. Your detection heuristics
would completely fail here, because there's no competition between a
blind or transparent attacker and the cache - the attacker *is* the

Also, you propose is that we just assume the answer we receive is
correct, and abort the transaction if it turns out not to be. But
the security handshake is probably finished at this point, and the
private data has been leaked to the attacker. And we don't *know*
that the data has leaked - we just think it has. So we're
potentially going to be exposing the user to false positives that will
train them to click through whatever warnings we might present.

You could kludge around this a bit by choosing a wait time shorter
than the maximum timeout, and not starting the transaction before
that. But to get any degree of reliability, I think you'd have to
introduce unacceptable delays.

Also, you assume that the application designers will get it right.
My app has to have a way of receiving an out-of-band notification from
the resolver to tell me to abort the transaction, and I have to abort
the transaction in a way that is appropriate to the circumstances, up
to and including telling the user they need to change their password

In the case of a web app, the engine that would have to make this
decision (the browser) doesn't really even know the security model of
the web app, so it's really not going to be able to give appropriate
advice to the user. This window of opportunity introduces a degree
of complexity to trusted apps that I think is unlikely to work in
practice, even if it could work in theory.

By contrast, if we validate the DNS response before we use it, we
close off these windows of opportunity completely. We certainly do
not eliminate all avenues of attack, but we do eliminate this one.

to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.