netdev - Re: [PATCH net-next 0/8] tou: Transports over UDP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 21 Jun 2016 10:23:25 -0700
From:	Tom Herbert <tom@...bertland.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	David Miller <davem@...emloft.net>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Kernel Team <kernel-team@...com>
Subject: Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On Tue, Jun 21, 2016 at 10:11 AM, Hannes Frederic Sowa
<hannes@...essinduktion.org> wrote:
> On 17.06.2016 20:52, Tom Herbert wrote:
>>
>>> > Rather, I think people are going to start adding rules to block TOU
>>> > tunnels entirely because they cannot inspect nor conditionally
>>> > filter/rewrite the contents.  This is even more likely if Joe Random
>>> > and so easily can do their own userland TCP stack over TOU.
>>> >
>> Unfortunately, encryption is the only proven solution to protocol
>> ossification. If the network doesn't see it, it can't ossify it.
>
> DTLS carries still a lot of information, both in its handshake, as well
> as in the actual framing. The protocol is basically only TLS on top of
> datagrams and as such implements connection establishment and tear down
> of connections, which middle boxes can certainly track. It will just be
> a matter of time until middle boxes and security appliances will be able
> to track those connections, maybe not being able to inspect the content
> but at least see the certificates in clear-text and as such also have
> the common names and other addressing information at hand. The meta-data
> might certainly be track able.
>
> Because of reply protection you actually can infer the number of bytes
> transferred and someone can end up building congestion control on a
> middle box based on that, infer retransmissions etc.
>
Right, it's probably impossible to completely eliminate track-ability.
But hopefully we can keep the plain text information to the absolute
minimum needed to send the packet over the network and decrypt it at
the receiver.

One interesting characteristic of disassociated location is that we
could purposely try to manipulate ECMP so that every packet for a flow
take different paths so no single device (assuming multi-path) can
reconstruct the whole communication (kind of like spread spectrum for
the Internet). I imagine there are some might be some environments
where paranoids might want to do this.

Tom

> Bye,
> Hannes
>