Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CANpvso4V67SBKn9+SXc+H=r-H-up+GWt77K4jH5HJx9k+sR+hA@mail.gmail.com>
 <CACXcFmkYtSeRMNTr=NXGK06MUyEnvaFqe_9Q11kWZq=f1ZdE_A@mail.gmail.com>
In-Reply-To: <CACXcFmkYtSeRMNTr=NXGK06MUyEnvaFqe_9Q11kWZq=f1ZdE_A@mail.gmail.com>
From:   Eric Curtin <ericcurtin17@gmail.com>
Date:   Wed, 27 May 2020 12:28:21 +0100
Message-ID: <CANpvso5xjawMVcRff-qbTeoPLkvyNNYCqdCuZYVEOYv-zsycQw@mail.gmail.com>
Subject: Re: Looking for an open-source thesis idea
To:     Sandy Harris <sandyinchina@gmail.com>
Cc:     Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        Kernel development list <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

Hi Sandy,

I actually have worked quite a bit with IPsec, it's not a protocol I'm
a huge fan of, it's use of multiple ports make it difficult to work
with middleboxs (be it load-balancers, TLS interceptors, reverse
proxies, proxies, firewalls, routers, switches, etc.). I've even seen
issues where some middleboxes only recognize TCP/UDP packets and not
ESP packets. There's so many implementations of IPsec with various
routers OS's and the standard seems to be only sort of universally
accepted. It can be difficult to deploy.

Although Wireshark does solve at many of these problems, it's simpler
at least, as regards VPNs I really like it. I'm actually more a fan of
protocols that applications have a little more control over like QUIC
over UDP or TLS over TCP.

I actually use HTTPS Everywhere plugin, but at the end of the day,
that simply just turns on TLS encryption if it's available right?

I like some of the problems QUIC solves, the multiple handshake
problem decreasing overall round trips, and just that it's more
modern. openssl is brilliant, but there's a lot of deadwood, older
encryption techniques in that codebase.

A monolithic secure TCP protocol seems like a nice idea, but maybe it
is too difficult.

I think it's a nice idea to explore OOM killer and compare it to the
solutions on various other OS's (FreeBSD, AIX, z/OS, Solaris, HP-UX,
macOS, iOS, Windows, Zircon, etc. and the OS I work on Powermax).
Thanks for that.

Any other ideas, keep them coming :)

On Tue, 26 May 2020 at 08:18, Sandy Harris <sandyinchina@gmail.com> wrote:
>
> Eric Curtin <ericcurtin17@gmail.com> wrote:
>
> > Hope I'm not bothering you. I'm looking for a masters thesis idea, ...
>
> > I'm really liking this
> > new QUIC (UDP) protocol as an alternative to TCP over TLS. And with
> > the growth of new modern secure protocols like Wireguard. I was
> > wondering, would it be an idea to do a monolithic secure TCP protocol
> > (as an alternative to TCP over TLS) as a small thesis project or is it
> > as hard as the guys at Google make is sound?
> >
> > "Because TCP is implemented in operating system kernels, and middlebox
> > firmware, making significant changes to TCP is next to impossible."
>
> I'm inclined to agree with the Google folk on that. However, what about
> IPsec? That was designed to secure anything-over-IP so it should be
> a more general solution. The FreeS/WAN project added opportunistic
> encryption for wider availability
> https://freeswan.org/freeswan_trees/freeswan-2.06/doc/intro.html#goals
>
> Today some opportunistic encryption protocols -- SMTP-over-TLS and
> HTTPS Everywhere -- are quite widespread but my impression is
> that opportunistic IPsec is not. Would adding it to an open source
> router be a thesis-sized project? Or, since routers likely have IPsec
> already, just making it easier to deploy?
>
> > I'm open to any other suggestions also for my thesis :)
>
> Linux's OOM killer strikes me as a spectacularly ugly kluge,
> but people who are certainly more knowledgeable and likely
> more competent seem to think it is necessary. Is there a
> thesis in examining it, looking at how other Unix-like systems
> handle the problem & perhaps implementing an alternative
> for Linux?