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

[Stephen Farrell]

If folks wanted to work on that RFC angle, I'd be delighted
to help out as I can.

I think that traffic analysis mitigation is the next big area
we need to start trying hard to work. So far, we've (IETF)
gotten general padding capabilities added to protocols (HTTP/2.0
for example, still in discussion for TLS1.3) on a case by
case basis, but we've not yet done anything systematic. I'd
love to see a WG chartered to try figure out how to most
effectively counter traffic analysis and then go write
protocol and/or BCPs as needed. (Speaking personally of
course, it'd require IETF consensus for that to happen
obviously.)

Pragmatically, it's very late for a BoF to happen at the
March IETF in Dallas. Deadline is Feb 6 for requests which
are mostly far more developed than one single email:-) But
if someone wanted to speak to the topic, we still have
space/time available in the agenda for the security area
meeting in Dallas. Ping me if you're interested and willing
and able to work on that.

Cheers,
S.


On 27/01/15 23:13, John Gilmore wrote:
> 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
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
> 
>