Hi,
and thanks for your feedback.

Am Mittwoch, den 14.02.2018, 20:23 +0000 schrieb Michael Tremer:
> Hi,
> 
> 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' ?

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).

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.

> > 
> > instead of '--tls-auth' to N2N connections which uses a static AES-
> > 256-CTR
> > whereby
> > a HMAC can not be selected ?
> The counter mode does not provide authentication like GCM does.
> 

Sure CTR is different to GCM but according to OpenVPN-2.4 manpage 
--> https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage ( under '--tls-crypt keyfile' ) 
it encrypts but also authenticates.
Logs from testings with --tls-crypt, AES-GCM for N2N looked like this:

Apr  7 16:59:58 ipfire UE2n2n[1530]: disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
Apr  7 16:59:58 ipfire UE2n2n[1530]: OpenVPN 2.4.1 i586-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Apr  5 2017

...

Apr  7 16:59:58 ipfire UE2n2n[1531]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Apr  7 16:59:58 ipfire UE2n2n[1531]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Apr  7 16:59:58 ipfire UE2n2n[1531]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Apr  7 16:59:58 ipfire UE2n2n[1531]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication

...

Apr  7 17:00:04 ipfire UE2n2n[1531]: Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Apr  7 17:00:04 ipfire UE2n2n[1531]: Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Apr  7 17:00:04 ipfire UE2n2n[1531]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 8192 bit RSA
Apr  7 17:00:04 ipfire UE2n2n[1531]: [xxx.xxx-gateway.de] Peer Connection Initiated with [AF_INET]91.192.xxx.xxx:61000
Apr  7 17:00:05 ipfire UE2n2n[1531]: Initialization Sequence Completed


So i would a kind of prepare this a little for a potential future
(deleting --auth from N2N.conf if GCM is used) but if there is a
decision in the future to use --tls-auth, the HMAC selection makes
sense even we use GCM. But since --tls-crypt uses only AES-256-CTR the
HMAC selection is useless if GCM has been chosen.

Sorry for the longer term thinking and possible confusions.

Greetings,

Erik