[Cryptography] Low grade randomness for padding.

[Phillip Hallam-Baker]

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.

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.

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.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210210/98ab0a33/attachment.htm>