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

[Donald Eastlake]

Hi,

On Tue, Jan 27, 2015 at 6:13 PM, John Gilmore <gnu at toad.com> wrote:
> ...  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

Energy-Efficient Ethernet was adopted as the IEEE Std 802.3az-2010
amendment to the 802.3 standard and has since been rolled into the
802.3 base standard (now 802.3-2012) where it is Clause 78. The 802.3
base standard document is so gigantic that it is divided into 6 parts.
This is in 802.3-2012_SECTION6 that you can get for free from
http://standards.ieee.org/about/get/802/802.3.html

> 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.

Right. Link level security, including padding / fake packets is the
way to go.

> 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.

You would expect link level security to be done by the organization
that specifies that link technology. Just what header fields exist and
which of them can be encrypted or need to be authenticated but can't
be encrypted, what limits their are on the packet size / re-ordering /
fragmentation and re-assembly / aggregation, etc., all affect link
security.

> 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.  ...

There is a fairly reasonably standard for Ethernet (i.e, 802.3) link
security.  It is IEEE Std 802.1AE-2006 (as amended by 802.1AEbn-2011
(GCM-AES-256) and 802.1AEbw-2013 (Extended Packet Numbering)), all
available from http://standards.ieee.org/about/get/802/802.1.html, and
is commonly known as MACsec. There is widely available hardware
support for 802.1AE. This is really specific to 802.3. For example I
believe it has some awareness of the padding needed because of minimum
Ethernet frame sizes. In my opinion it should have been an 802.3
standard (or the 802 Security WG, 802.10, should have been revived but
that's another story).

(By the way, I don't like the style of 802 documents, but your mileage
may vary...)

Key agrement/management is not specified in 802.1AE. It assumes you
would use 802.1X (which in turn uses EAP) but you could use some other
scheme to key 802.1AE.

> 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.

If this is link level, why does it have anything to do with IPv4/IPv6?
Just doing it for IPv4 and IPv6 would help but what about ARP which is
essential for but not part of IPv4? Or, in the real world, what about
MPLS or TRILL or the like which are used to transport traffic over
links and would encapsulate IP?

> 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.

>From the point of view of 802.1AE, Ethernet/802.3 is very simple. VLAN
tags are just a sequence of bytes that are part of the payload without
any semantic content.  But that is because 802.1AE is really at the
802.3 link level in that it operates just between adjacent Ethernet
ports. If, say, Router A (RA) is talking to Router B (RB) directly
over Ethernet, then 802.1AE secures the traffic between the RA port
and the RB port. But if, say, there is an intervening customer bridge,
then it would secure the traffic between the RA and RB ports and the
bridge ports to which they directly connect, leaving traffic in the
clear inside the bridge (although, of course, it could have been
encrypted at a higher layer like IPsec).

This seems to correspond to what you were contemplating above since
any synthetic traffic need only be one 802.3 hop.  This is also
inherent in the way 802.1AE works and the way 802.1 VLAN aware
bridging works. Since 802.1AE is VLAN ignorant, just as 802.3 is, it
just pushes a tag on the front of the frame and encrypts everything
after that, including any VLAN tags that might be there. But bridges
enforce VLAN separation and so must see the VLAN tags to be sure they
don't send a frame in one VLAN to a station not authorized for that
VLAN.

> 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.

I would call essentially all of Wi-Fi "connection based"; not just
Infrastructure mode where you have an Access Point (AP) and associated
non-AP stations but also ad-hoc (IBSS) mode, mesh mode peering,
etc. That is because it is essential that Wi-Fi stations come to
agreement on the frequency and bandwidth they are using, the data
speeds/modulations available, as well as normally having to agree on
QoS parameters and security before they communicate any data, not to
mention beam forming and MIMO stuff.  This requires what could very
reasonably be called a "connection protocol" before you can ship any
data.

(The only exception is OCB mode (Outside the Context of a BSS, aka
802.11p) which is what will be used for the so called ITS (Intelligent
Transportation System) 802.11 stuff between vehicles and between
vehicles and roadside equipment. The timing constraints there are so
tight you just send a data frame and hope for the best, which requires
fixed pre-specification of frequency, bandwidth, data speed, etc.)

People from the wired world usually fall into the trap of thinking
that Wi-Fi is just another physical medium, perhaps as trivially
different as copper and fiber are from each other. Not so.

By the way, I am the Chair of the 802.11 Task Group (802.11ak) that is
working on an amendment to the 802.11 standard so that 802.11 links
can be use as through links inside networks as well as links to leaves
at the edge of the network. (That was already true for Wi-Fi mesh but
what people are really interested in is using AP to non-AP station
links as through links in a standard way (many proprietary systems do
this now).) What with multi-gigabit 802.11ad links, people
increasingly want to do this, even inside data centers for overflow
traffic and the like.  See
http://www.ieee802.org/11/Reports/tgak_update.htm. There has already
been some informal pressure from wired folks to, for 802.11ak links,
make 802.11 security "~compatible~" with 802.1AE.

> 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).

802.11 (Wi-Fi) is an entirely different link technology and as such it
inherently needs security with different details. WPA (Wi-Fi Protected
Access) is a creation of the Wi-Fi Alliance, an industrial group, not
part of the standard, and it just has to do with keying as I
understand it.  The basic formats and algorithms (ignoring the early
algorithms adopted due to hardware limitations and which are now
deprecated) are OK as far as I know. 802.11 security doesn't require
that you use passwords and, if you do, doesn't require that the
password be the same for all associating stations, and even if the
password is the same, I believe you have to observe the initial
handshake as their are nonces involved such that the pairwise keys
between an AP and each associated station are different even if they
used the same password. 802.11 Security is mostly in Clause 11 of IEEE
Std 802.11-2012 (available free from
http://standards.ieee.org/about/get/802/802.11.html (you may be
noticing a pattern here)).

For examples of the differences, the only real "header" on an 802.3
frame is the Destination Address / Source Address and the trailer is
the padding sometimes required on short frames and the CRC. The 802.11
frame is much more complex with a variety of types (see Clause 8 of
IEEE Std 802.11-2012) so there is additional meta data that needs
authentication.  Then there is the level security operates at.  For
802.3, it is a frame. But 802.11 operates in such a variety of
environments and modes that, to help with the overhead of acquiring
the over-the-air channel, it has three different types of aggregation
(MSDU (MAC Service Data Unit) aggregation, MPDU (MAC Service Protocol
Unit) aggregation, and PPDU (PLCP (Physical Layer Convergence
Procedure) Protocol Data Unit) aggregation. And, to help when things
are noisy, it has fragmentation.  802.11 security is at the fragment
level, not the frame level, so you can't screw up the receiver by
injecting lots of fake fragments.

People from the wired world, at least the higher end wired world, tend
to view link security as something very expensive requiring special
hardware deployed only in special high risk cases. People from the
802.11 world realize that their communications are always exposed and
at risk so security hardware is always built into the chip sets. Since
the hardware is always sitting there anyway, 802.11 people tend to
consider encryption free and it is almost always used.

802.15 (Bluetooth, Zigbee, etc.) is working on security and I feel
reasonably confident that, at the low level, 802.3, 802.11, and 802.15
security will not be compatible.  But things could be compatibility at
other levels, like using the same certificates if you choose to do
certificate based authentication or the same crypto algorithms.

> 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.

Perhaps improved key agreement and algorithms including padding for
802.1AE is the way to go...  There is currently an amendment in
progress for 802.1AE designated 802.1AEcg
(http://www.ieee802.org/1/pages/802.1aecg.html) to specify transparent
MACsec devices which may or may not be relevant.

> 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.

PPP is a link technology standardized by the IETF so here is a case
where the IETF should specify security for the link protocol.

As you point out, the existing PPP security protocols do not meet
modern standards for security. For a while, I was chair of the IETF
PPPEXT WG (PPP Extensions Working Group) until it was dissolved and I
tried to stir up some interest in updating the PPP security standards
with no success. Of course, it could be that I was just not very
effective in this "stirring up" and/or the PPPEXT mailing list
subscribers were not the best/right audience. I don't think pure
legacy PPP over HDLC is the future. PPP is going to be over Ethernet
or something so I think this can be fixed as the bearer link protocol
layer although there certainly wouldn't be anything wrong with fixing
it at the PPP layer.

Anyway, I'd be happy to participate in an improved link security effort.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3 at gmail.com

>         John