Saving Opportunistic Encryption

[Thomas Shaddack]

On Wed, 17 Mar 2004, Eugen Leitl wrote:
> On Tue, Mar 16, 2004 at 03:29:42PM +0800, Sandy Harris wrote:
>
> > >So, the apparent solution for me seems to be the approach that the SPAM
> > >blacklists used - publish information in a subspace of the forward DNS
> > >space instead of using the authoritative in-addr.arpa area.
> > >
> > Worth discussing at least.
>
> No, anything requiring publishing DNS records won't fly. OE is
> *opportunistic*. It doesn't care about what the true identity of the opposite
> party is. Any shmuck on dynamic IP should be able to use it instantly, with
> no observable performance degradation, using a simple patch.
>
> If it doesn't fit these minimal requirements, it will die, just the same way
> FreeS/WAN did.

I discussed it with friends. There could be a way to advertise the OE
availability, at least for TCP connections; my original idea was to use
some magic number in the payload (which is normally zero) in the TCP/SYN
and TCP/SYNACK packets. I was advised against this, as these packets are
likely to be thrown away, and got suggested that there are various TCP
options in the header. Maybe we could hijack one of them, eg. use the MD5
checksum option otherwise used by BGP (RFC 2385) to advertise our support
for OE. The field is 128 bits of data we can use for a magic number and a
bitfield of options. It is defined in RFCs, so it should be valid. We
could put it into TCP/SYN packets when opening a connection, to advertise
we support OE; the server then can use the same mechanism to send back
confirmation of its OE support, and the method (if present) that can be
used for authenticating its identity.

The disadvantage is that we still have some risk that some routers will
throw such packets away; see the problems eg. ECN has. However, some RFC
offers a remedy for this, as it defines that if the first TCP/SYN with ECN
support set doesn't get a SYNACK, the retry is WITHOUT the ECN offer.
(This principle introduces the possibility of failure to use OE if the SYN
packet with the OE (or the corresponding ACK) offer gets dropped due to
congestion, but it should introduce no additional overheads (except the
need to retry TCP/SYN in case it gets dropped due to non-RFC-compliant
infrastructure on the link).

Another disadvantage is that we don't protect UDP, due to lack of the
header options.

The advantage could be the possibility to implement this transparently on
eg. the firmware of a NAT box; it has to track the connection states
anyway, so it should be capable of mangling the first TCP/SYN packet by
putting the OE offer in, and then strip it from the answers before
passing it back, and handle the encryption in transparent manner. This way
we got big savings in terms of effort needed to deploy OE between a
heterogenous LAN and the Net; just upgrade the router.

This scheme, as all OE are, is susceptible to an attack by stripping the
OE offers from the packets. It, however, is not the passive way anymore,
is more expensive, poses more difficulties, and a variant of eg.
"arpwatch" userspace daemon can alert us that something like that is
happening, that sites that used to use OE don't do so anymore, or that
their identities are suspiciously changed.

Told something like this to the crew of OpenSWAN developers. Got some
reaction, but it's too soon to know more.

Opinions, comments?