From: Duane <duane@e164.org>
The point he was trying to make about no authentication is the requests
can be intercepted and proxied, just because you have a secure channel,
doesn't mean you know who it's to.
i understood that perfectly. my counter response was that this is fine for
the purpose of stub/RDNS relationships as long as they are SSH-like in that
there is an expensive setup involving a generated shared secret and another
expensive randomly periodic key rollover. these will have to be retriable
in the event of possibly-spoofed ICMP based failures, and any UDP/53 fallback
has to be configurably turn-off-able.
under those conditions, an instruction from DHCP of "use RDNS a.b.c.d" is
sufficient since "who i think it is" is a.b.c.d and that is indeed who it
will be to. if an ISP wants to launch a provider-in-the-middle attack, they
will have to be able to spoof the address i wanted to reach, persistently,
in order to do the secret-exchange dance, both initially and at rollovers.
the case i'm guarding against is when i think i'm talking to a.b.c.d and i'm
really not. an ISP who can spoof a.b.c.d persistently is dangerous and
annoying, but not so dangerous as someone who isn't my ISP spoofing it in a
flood of QID-guessed responses as was demonstrated last year by amit klein.
again, i really don't care to change the method by which a stub learns to
use a given RDNS, and that method is, "use a.b.c.d". no keys, no secrets,
no identity information. but with sufficient state, this can be made more
secure than it is now.
(fallback in a hotel room is interesting. if the prospective new protocol
does not work, would a hotel visitor prefer no internet service at all, or
would they drag out their VPN machinery, or would they just send their DNS
queries in UDP/53 and be mightily suspicious about what came back? this is
interesting in like of KRE's observation that DNS spoofery may be necessary
to preserve the illusion of IPv4 reachability when we run out of new IPv4
addresses but want to keep growing with IPv4.)