mirror of
https://gitlab.com/fabinfra/fabaccess/fabaccess-api.git
synced 2025-03-12 14:51:42 +01:00
93 lines
4.7 KiB
Markdown
93 lines
4.7 KiB
Markdown
# 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 -->
|
|
|
|
* [Transport Layer Security (TLS)][TLS]
|
|
* [Datagram Transport Layer Security (DTLS)][DTLS]
|
|
* [Noise Protocol Framework][noise]
|
|
* [TLS Application-Layer Protocol Negotiation Extension (ALPN)][ALPN]
|
|
* [Stream Control Transmission Protocol (SCTP)][SCTP]
|
|
* [Heartbleed]
|
|
* [LogJam]
|
|
* [Datagram Transport Layer Security for Stream Control Transmission Protocol][sctp-dtls]
|
|
|
|
[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
|