[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: opportunistic encryption deployment problems
I very much like the concept of opportunistic use of IPsec, but I'm
deeply concerned about several aspects of the FreeS/WAN approach.
There is (at least) one significant additional opportunity for
mischief in the absence of DNSSEC: because the DNSSEC record contains
not only IPsec parameters, but also a "tunnel to" address, it provides
an additional mechanism to subvert the routing of IP datagrams.
While an attacker capable of spoofing DNS might also be able to spoof
the A record, a spoofed "A" record:
- will be visible to applications and in logs
- will be trivially visible in traditional system status tools (e.g.,
netstat output).
If we assume spotty DNSSEC deployment (almost a certainty), the
combination of a secured forward zone and an unsecured inverse zone is
extremely likely, and in this case, an unauthenticated tunnel-to
address is particularly problematic.
I'd like to suggest two changes to the proposal:
1) in the absence of a secured inverse zone, disallow use of a
tunnel-to address different from the end system's address.
Alternatively, just use transport mode..
2) Add a (necessarily unauthenticated) request-response protocol
(perhaps using IKE NOTIFY messages?) to attempt to determine whether a
destination is OE-capable, to be used if the appropriate reverse DNS
zone is insecure or does not contain OE info. This also quite
effectively deals with the very common case where the host's
administrator has no control of the contents of the inverse zone.
While it's outside the scope of a protocol specification, the spec
should recommend that, in the absence of some form of certification,
implementations should make {dnsname,address}->key mappings "sticky"
using techniques similar to those currently used by ssh.
I also think that some more thought should be given to ways to use
opportunistic encryption in conjunction with the NAT traversal drafts;
the current draft encourages using cleartext communications on the
"inside" of the NAT, which is clearly the wrong answer when there's
802.11 on the "inside" of the NAT..
- Bill
Follow-Ups:
References: