Require the use of transport encryption

Status: accepted
Deciders: @dequbed, @TheJoKlLa, @kjkriegel

Context and Problem Statement

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

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

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

Reliable transport encryption is ensured
PKI structure of TLS can easily solve the inherent trust establishment problem in a federated setting

Negative Consequences

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

TLS

Use the known and proven TLS protocol

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

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 (bffhd), C# (Borepin), Python(1, 2) (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.

4.8 KiB Raw Blame History