From 5de7dc2ef36b71a56b8c22836dce88cc2cf789de Mon Sep 17 00:00:00 2001 From: Nadja Reitzenstein Date: Wed, 5 Jan 2022 17:31:29 +0100 Subject: [PATCH] Transport encryption ADR --- ...001-require-strong-transport-encryption.md | 86 +++++++++++++++++++ docs/decisions/index.md | 1 + 2 files changed, 87 insertions(+) create mode 100644 docs/decisions/0001-require-strong-transport-encryption.md diff --git a/docs/decisions/0001-require-strong-transport-encryption.md b/docs/decisions/0001-require-strong-transport-encryption.md new file mode 100644 index 0000000..d558d82 --- /dev/null +++ b/docs/decisions/0001-require-strong-transport-encryption.md @@ -0,0 +1,86 @@ +# Require the use of transport encryption + +* Status: accepted +* Deciders: @dequbed, @TheJoKlLa, @kjk + +## 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 + +* [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 + +* 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][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. + +* 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 + +* [Link type] [Link to ADR] +* … + +[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 diff --git a/docs/decisions/index.md b/docs/decisions/index.md index 37ef8b8..2ab5d0c 100644 --- a/docs/decisions/index.md +++ b/docs/decisions/index.md @@ -5,6 +5,7 @@ This log lists the architectural decisions for [project name]. * [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