[Cryptography] traffic analysis -> let's write an RFC?

John Gilmore gnu at toad.com
Tue Jan 27 18:13:10 EST 2015


Jerry Leichter wrote:
> > Different network designs can also help.  If you own the link and both of
> > its ends, it costs you exactly the same to send continuous random bits as
> > to leave the line idle. 

Ben Laurie wrote:
> Yeah, but ... who can realistically afford that bandwidth? 

Your employer Google can - it owns the fibers among its data centers
(and many other fibers, I believe).  Clearly, Jerry's remark ("If you
own the link") was addressed to link-level encryption.

Actually, there *is* a cost of running dummy traffic or continuous
random bits.  It's the cost of the excess power required, plus the
one-time cost of acquiring the hardware and software required.  The
power consumption of Ethernet interfaces, for example, has been
reduced significantly when idle, over the last decade
(https://en.wikipedia.org/wiki/Energy-Efficient_Ethernet).  But
Jerry's main point, that that cost is minimal in the overall long term
cost of acquiring and operating an active link, is accurate.

> To every possible recipient? Clearly you have to make a tradeoff.

The traffic that goes down a fiber to the other end of the link IS to
every possible recipient.  Or rather, traffic to every possible
recipient at the other end of the fiber, goes down that fiber.  So,
yes.  But of course link-level chaff traffic will be stripped out at
the other end of the link, so it will not reach every possible
recipient; indeed, it will not reach ANY possible recipient.

If you merely encrypt transport layer packets (IP packets), as in
IPsec, their destinations are visible.  So you have to do link
level encryption to prevent traffic analysis.

I think it's significant that there is no RFC standard for encrypted
link-level traffic, either with or without with dummy traffic, and no
free software implementation either.  We on this list could do a lot
to improve that situation.

Most local and long-haul networks are now based on Ethernet protocols
(with an increasing market share in future).  A typical fiber-optic
link that carries Internet traffic has an Ethernet switch at both
ends, since they are so much cheaper and more flexible than ATM and
SONET switches, the main alternatives.  The mass market for Ethernet
has driven prices to where a $500 retail switch plus a few $100 GBIC
adapters can drive multiple 1-gigabit fibers over 50 to 80 km, plus
switch dozens of local gigabit Ethernet ports.  Doing this with telco
equipment is orders of magnitude more expensive.

We should consider writing an RFC based on RFC 894, "Standard for the
transmission of IP datagrams over Ethernet networks", that provides
for link-level encryption of all packets transmitted, and for
transmitting dummy encrypted traffic that the recipient will
automatically discard.  Plus a similar version for IPv6 (RFC 2464),
and possibly for PPP (RFC 1661), which is used over modems, and I
think is also used over DSL.

Or, should this be done directly at the Ethernet layer and at the PPP
layer, rather than at the interface between the physical layer and the
link layer?  The Ethernet layer is a much bigger mess, with more
signalling complexity, multiple layers of headers for VLAN support,
etc.

There is a similar standard for WiFi (which is Ethernet based) but
only for connection-based ("access point") WiFi, which is very unlike
ordinary Ethernet.  WiFi encryption has major issues, though, such as
using the same key for every node (if you know the WPA password, you
can snoop all the traffic, not just the traffic for your own node),
and failing to encrypt by default (if there is no WPA password, then
traffic is passed in the clear).

If such an Ethernet standard catches on, the protocol will be pushed
into switch hardware and Ethernet host interface chips, and will
result in minimal costs to deploy encrypted links with dummy traffic.
The key is to make it like everything else in Ethernet -- you plug it
together and it just works.  I don't want to pre-judge the design of
such a standard, but it should act like OTR in the sense that it
automatically detects compatible endpoints, negotiates session keys
automatically to encrypt against passive attacks (e.g. via
Diffie-Hellman), yet provides a manual option to lock down the
endpoint identities to detect and prevent active attacks.

PPP already has a link-level encryption standard, RFC 1968, updated by
RFC 2420 for 3DES.  But no AES option has been standardized for PPP,
nor is there any key negotiation protocol; these PPP standards assume
that DES or 3DES keys have been manually pre-negotiated and locally
stored.  Also, the existing standard leaks the value of the last byte
of plaintext, in its padding algorithm.  So, there remains serious work
to build a usable PPP encryption standard too.

	John


More information about the cryptography mailing list