Hello,
first of all. May it is better to wait with the introduction of AES-GCM 
until OpenSSL-1.1.0g + OpenVPN-2.4.4 has been released, or what do you
think ?

> > > 
> > > On Wed, 2018-02-14 at 20:11 +0100, ummeegge wrote:
> > > > 
> > > > 
> > > > As a version 3 idea,
> > > > or might it be possibly a better idea to delete the '--auth *'
> > > > directive in
> > > > N2N.conf
> > > > if AES-GCM has been chosen ? i think it might also be better to
> > > > integrate
> > > > '--tls-crypt' --> https://www.mail-archive.com/openvpn-
> > > > devel(a)lists.sourceforge.net/msg12357.html 
> > > I do not get any of those arguments in that email. I find that
> > > highly
> > > useless
> > > for a legitimate use of VPNs.
> > > 
> > Not sure what you exactly mean with 'useless' ?
> I thought some of that is a bit esoteric cryptography.

:D i see, you are also right this is a kind of esoteric in the true
sense of the word (designed for or understood by the specially
initiated alone ;) .
> 
> Hiding the TLS connection makes sense when you are in China behind
> the big
> state-run firewall, but that is about it.

Not only, to some extend the Heartbleed vulnerability for example was not exploitable
with an active --tls-auth (--tls-crypt serves the same mechanism)
--> https://community.openvpn.net/openvpn/wiki/heartbleed but OpenVPN do also
strongly encourage to use such protections 
--> https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-auth .

> 
> I mean I am not against it, but this is pretty useless and probably
> only creates
> many confusing configuration options for the average user.

Have integrated it some months ago in my environment (works here
without problems) and it can be activated via one checkbox 
https://people.ipfire.org/~ummeegge/screenshoots/OpenVPN-2.4_beta2/N2N_tls-crypt.png
same like --tls-auth which IPFire serves for Roadwarriors since 2 or 3
years meanwhile.

> 
> > 
> > Just to clarify, --auth HMAC is also used by --tls-auth which
> > serves a
> > separate layer of authentication protection for the control channel
> > (to
> > mitigate DoS attacks and attacks on the TLS stack).
> > 
> > --tls-crypt is a new feature in v2.4 which not only authenticates
> > (like
> > --tls-auth do), but also encrypts the TLS control channel (more
> > privacy) but uses AES-256-CTR instead of the --auth HMAC (also
> > called
> > "poor-man's" post-quantum security).
> I am never a fan of non-standard cryptography. Has this been properly
> peer-
> reviewed?

I think it has also been reviewed while the v2.4 security evaluation
from Quarkslabs and PrivateInternetAccess 
https://blog.quarkslab.com/resources/2017-05-11-security-assessment-of-openvpn/17-03-284-REP-openvpn-sec-assessment.pdf
take a look into the 'Recommendations' section under '2. Executive Summary' .
But it is also meanwhile widely used on other distros e.g. https://redmine.pfsense.org/issues/7071 
but also by some VPN providers i think.

> 
> > 
> > Both options are currently not available for N2N but may in the
> > future.
> > So i thought it might be better to delete the '--auth HMAC'
> > directive
> > in N2N.conf if GCM has been selected.
> GCM already has the authentication built in.

This are two different layers of security in my opinion whereby both
directives do offers a 2nd line of defense if a future flaw is
discovered in a particular TLS cipher-suite or implementation, whereby
--tls-crypt encrypts also the control channel.
A little deeper explanation can also be found in the hardening wiki or
in here 
http://archive.openvpn.net/pipermail/openvpn-devel/2016-July/024892.html
for a little more info causing --tls-crypt .

> 
> The --tls-crypt is something that should never be enabled by default.
> But if you
> want to have it, add it.

Think so and i haven´t it enabled by default, integrated it in the same
way as --tls-auth is already integrated, ticking a checkbox and ready.

But as mentioned this is a future sound of music and i would wait with
this since there are more important things i think (--ncp-cipher, AES-
GCM integration, deprecated directives such as comp-lzo, ...).


Most important for me was to come to a decision for the AES-GCM patch
if i should delete the 'auth' directive (needed only for --tls-auth
since it use the same HMAC then the old ciphers) if a GCM cipher has
been chosen and i think i will do this to keep the house clean so to
say ;-).


Greetings,

Erik