Implementers of the API should use some level of transport encryption for any
non-local communication because it's not the 2000's anymore and our crypto is
actually good, cheap and secure.
## Decision Drivers <!-- optional -->
* The software stack in question has a decent amount of security relevance, even when only used in a LAN context.
* Since most users of the API connect via WLAN and most of those are using PSK, eavesdropping is trivial
## Considered Options
* [TLS]
* [DTLS]
* [Noise protocol][noise]
## Decision Outcome
Chosen option: "TLS", because TLS overall is the easiest to implement for the
remaining stack as it currently stands and most sysadmins have a good
understanding of the PKI of TLS.
### Positive Consequences <!-- optional -->
* Reliable transport encryption is ensured
* PKI structure of TLS can easily solve the inherent trust establishment problem in a federated setting
### Negative Consequences <!-- optional -->
* Generating a trusted X.509 certificate is required for federated application incurring either monetary cost or additional setup work
* Encryption overhead is a relevant factor in ultra-low-powered devices in cases with a for that use-case badly configured server (i.e. not offering ChaCha20 and other computationally cheap algorithms)
## Pros and Cons of the Options <!-- optional -->
### TLS
Use the known and proven TLS protocol <!-- optional -->
* Good, because TLS support is ubiquitous on all platforms
* Good, because TLS allows to negotiate cipher algorithms allowing different devices to chose the cipher best suited for them
* Good, because TLS offers extensions, e.g. [ALPN] that make protocol versioning easier
* Bad, because TLS is not well suited for [SCTP] which the protocol in future wants to switch to
* Bad, because TLS is inherently very complex and has suffered from many attack vectors, best known e.g. [Heartbleed] and [Logjam] that require extra caution when configuring TLS
* Bad, because TLS' cipher negotiation (especially below version 1.3) is susceptible to downgrade attacks, especially in the case of a `STARTTLS`-style usage.
### DTLS
Use the [Datagram Transport Layer Security][DTLS] which is an IETF protocol similar to TLS but specifically designed for message-orientated protocols where message losses and reoderings have to be tolerated.
* Good, because it shares most of the advantages of TLS but also [more ergonomically works with SCTP][sctp-dtls]
* Bad, because DTLS is significantly less well supported than TLS
* Bad, because DTLS has no equivalent for TLSv1.3 which adds significant improvents over TLSv1.2 in terms of security
### Noise protocol framework
Use encryption based on Noise, a framework with support for mutual and optional authentication, identity hiding, forward secrecy, zero round-trip encryption, and other advanced features. <!-- optional -->
* Good, because it has no design for cipher negotiation making downgrade attacks impossible
* Good, because the lightweight nature of noise and the ciphers chosen means it has very limited impact compared to TLS or DTLS
* Good, because noise lends itself very well to a system where encryption keys are shared via side-channel, e.g. by scanning a QR code also containing the address to connect to.
* Bad, because platform support is very limited compared to TLS/DTLS, although the most important ones i.e. [Rust][noise-rust] (bffhd), [C#](noise-csharp) (Borepin), Python([1][noise-python1], [2][noise-python2]) (pyfabaccess) are covered.
* Bad, because noise requires more implementation work than TLS in terms of numbers of lines of code and in decisions to make.
