[Cryptography] Low grade randomness for padding.

[John-Mark Gurney]

Phillip Hallam-Baker wrote this message on Wed, Feb 10, 2021 at 11:40 -0500:
> On Wed, Feb 10, 2021 at 11:13 AM Kent Borg <kentborg at borg.org> wrote:
> 
> > On 2/9/21 12:40 PM, Phillip Hallam-Baker wrote:
> >
> > So, the last thing I need to write for the Mesh is a presentation layer.
> > This has the primary function of providing authentication over HTTP and
> > encryption and authentication over UDP.
> >
> > The UDP packet format is intentionally as opaque as possible, there are
> > two basic types of packet
> >
> >
> > The responses all seem concerned with padding being a covert channel risk.
> >
> > Another concern is leaking data through message length. (Encrypted voice
> > can frequently understood just on data sizes over time.) Padding with
> > random data fights that
> >
> And packet timing...
> 
> As with QUIC, I am using fixed sized packets (1200 bytes), precisely to
> conceal the message length.

+1

> This has got me back to an old gripe I have about the idiocy of Ethernet
> jumbo frames being limited to 9000 bytes which really isn't much of an
> improvement. The justification for the stupidity is that CRC checksums
> don't work on longer packets. Which is of course a stupid argument when we
> are talking about a network predicated on the end-to-end principle.

And modern protocols should be doing their own strong verification of
contents (TLS, ssh, etc), which makes the CRC just more about protecting
interrupting the session when bad data gets through than it is about
integrity.

Also, w/ Path MTU discovery, and other measures (automtud), you can turn
on Jumbo frames on your local network and still have it work w/ systems
that don't support jumbo frames.

> The more packets you have, the more work the routers have to do.
> 
> What I would do to fix this is to
> 
> 1) Strip out all legacy support at the link layer for non-IP protocols.
> Ethernet MAC addresses serve no function, kill them. WiFi etc. need
> identifiers but they don't need to be visible above the WiFi layer. Use IP
> to route on the LAN, it is what it is for.

To be compatible w/ existing networks, you could just move the IP
addresses into the MAC address field, allowing modern hardware to still
work (assuming it allows the MAC address filter to be changed).

> 2) Introduce a Jumbo packet with a maximum size limited only by the IP
> packet size of 64KB minus a few hundred bytes to allow the link layer room
> to work within packets described by a 16 bit length.
> 
> 3) Limit the link layer checksum to the first 128 bytes of the packet. This
> helps prevent errors causing packets to be mis-routed which is a link layer
> concern.
> 
> 4) Make integrity of the payload purely the concern of the transport and
> presentation layers. Once we decide that packets are going to be encrypted
> using AEAD, we have no need for link layer integrity checks on the payload.
> Just get rid of them.

+1

> I see integrity checks at the link layer as being more of a network
> diagnostic than a data integrity mechanism. If you have 5% of packets
> throwing CRC checks, there is an intermittent problem with the cable or the
> line that needs fixing. The CRC check does not need to be 100% accurate to
> be sure.

Yep, if the link is throwing errors, even if only 1% of the payload is
protected, you'll still get enough errors (via switch stats) to justify
investigation to figure things out (or you should have that monitoring
in place)..

> We might even want to go further and mandate that if a linkis throwing more
> than x% errors, it MUST be shut down to prevent bogus packets being
> injected that load up the routers.
> 
> Problem here is that the folk at the lower end of the stack and the folk at
> the upper end of the stack don't often talk to each other. I know the IETF
> is allegedly designed to make this happen but it doesn't. Ask a routing
> person what function the CRC or the MAC address perform today and they go
> straight into alchemy.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."