Transport encryption ADR

docs/decisions/0001-require-strong-transport-encryption.md

@@ -0,0 +1,86 @@
+# Require the use of transport encryption
+
+* Status: accepted <!-- optional -->
+* Deciders: @dequbed, @TheJoKlLa, @kjk <!-- optional -->
+
+## 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 <!-- 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.
+
+## Links <!-- optional -->
+
+* [Link type] [Link to ADR] <!-- example: Refined by [ADR-0005](0005-example.md) -->
+* … <!-- numbers of links can vary -->
+
+[TLS]: https://en.wikipedia.org/wiki/Transport_Layer_Security
+[DTLS]: https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security
+[noise]: http://www.noiseprotocol.org/
+[ALPN]: https://datatracker.ietf.org/doc/html/rfc7301
+[SCTP]: https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol
+[Heartbleed]: https://heartbleed.com/
+[LogJam]: https://weakdh.org/logjam.html
+[sctp-dtls]: https://datatracker.ietf.org/doc/html/rfc6083
+[noise-rust]: https://github.com/mcginty/snow
+[noise-csharp]: https://github.com/Metalnem/noise
+[noise-python1]: https://github.com/plizonczyk/noiseprotocol
+[noise-python2]: https://github.com/tgalal/dissononce

docs/decisions/index.md

@@ -5,6 +5,7 @@ This log lists the architectural decisions for [project name].
 <!-- adrlog -- Regenerate the content by using "adr-log -i". You can install it via "npm install -g adr-log" -->
 
 * [ADR-0000](0000-use-markdown-architectural-decision-records.md) - Use Markdown Architectural Decision Records (MADR)
+* [ADR-0001](0001-require-strong-transport-encryption.md) - Require the use of transport encryption
 
 <!-- adrlogstop -->