[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: opportunistic encryption deployment problems

Wes Hardaker wrote:
> 
> 3 problems I see with the deployment of opportunistic encryption:
> 
> 1) your method of obtaining information is by reverse DNS lookup,
>    which will provide problems with people who can't control their
>    reverse DNS bindings.  As an example, I don't have control over the
>    subnet mapped to my house and can not insert information into the
>    controlling DNS server (and can not convince them to redirect to
>    me).

Yes, but what alternatives are there, short of giving up on DNS and
mandating that anyone wanting to do opportunistic encryption must
have a particular type of PKI infrastructure in place?

What is really wanted is support in the DNS for inverse queries, as
Henry says in a document that preceeded the ID:

http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/opportunism.spec

> Inverse queries, an obscure DNS feature from the distant past,
> in  theory  can  be used to ask a DNS server to reverse that
> lookup,  giving  the  name  that  produced  the address.
> This is not the same as a reverse lookup, and the difference can
> matter a great deal in  cases  where  a  host does  not  control
> its reverse map (e.g., when the host's IP address is dynamically
> assigned).   Unfortunately,  inverse queries were never widely
> implemented and are now considered obsolete. 

I suppose we could be trying to convince DNS implementors to support
them, but it seems unlikely we could do that. Even if we succeeded,
we'd still need a fallback mechanism for the situations where such
support wasn't in place.

Putting keys in the forward maps has some nice consequences, but
also some serious problems.

It goes a long way toward solving the problem for people with
dynamic addresses. All we need to do is persuade the providers of
dynamic DNS services to include keys. Well, not quite all. We
have to work out how they can do that securely, and persuade
them to implement secure DNS, and get things signed and ...

It may also make connection setup faster. In the current design,
the sequence is often:
	client does forward lookup to get IP address
	client builds and sends packet
	gateway interecepts packet
	gateway does reverse lookup to get key
	gateway starts negotiation
If we could change it to:
	client does forward lookup to get IP address
	gateway gets key as a byproduct
	gateway starts negotiation
that would involve less delay.

However, short of requiring that every IPsec gateway run a DNS daemon,
that clients all use that as their DNS server, and that the daemon be
modified for some extra functionality (roughly equivalent to inverse
queries), this does not work.

Even if the responding DNS delivers key information from a forward map
in response to client queries, the gateway has no way to get that info.
All it sees is a packet with an IP address. It can get key info from a
reverse map in one lookup. If the info is in a forward map, it needs
two lookups and there can be complications with multiple names.

Just taking the overhead hit and telling it do the two lookups doesn't
work. In the situation you mention -- dynamic address and no control
over the  reverse map -- the reverse does not point to the name we 
want used in the subsequent forward lookup.

Even in cases where it does give the right answer, the extra overhead
of two lookups is a problem. Opportunistic must be fast; there are user
packets waiting for the connection to be set up or declared unavailable.

If we do specify a DNS daemon on the gateway and arrange for it, on
doing a lookup for a client, to get a key if possible and pass it
(how?) to IPsec, we still have problems. Clients will sometimes use
addresses without first looking up the names, so we need another
mechanism for that case. 

Also, it is by no means clear that requiring a DNS server on the
gateway will fit into local security policies.
References: