\label{section:PKIs}
Public-Key Infrastructures aim to provide a way to simplify the verification of
-a certificates trustworthiness. For this, certificate authorities (CAs) are
+a certificate's trustworthiness. For this, certificate authorities (CAs) are
used to create a signature chain from the root CA down to the server (or client).
Accepting a CA as a generally-trusted mediator solves the trust-scaling problem
at the cost of introducing an actor that magically is more trustworthy.
This section deals with settings related to trusting CAs. However, our main
-recommendations for PKIs is: if you are able to run your own PKI and disable
+recommendation for PKIs is: if you are able to run your own PKI and disable
any other CA, do so. This makes sense most in environments where any machine-to-machine
communication system compatibility with external entities is not an issue.
%% azet:
%%mechanism.
%% ^^ commented out due to duplication (see previous section on architecture) - azet
-Many of the parts in a ciphersuite are interchangeable. Like the key exchange algorithm in this example:
-\texttt{ECDHE-RSA-AES256-GCM-SHA384} and \texttt{DHE-RSA-AES256-GCM-SHA384}.
-To provide a decent level of security, all algorithms need to be safe (subject to
-the disclaimer in section \ref{section:disclaimer}).
+Many of the parts in a ciphersuite are interchangeable. Like the key exchange
+algorithm in this example: \texttt{ECDHE-RSA-AES256-GCM-SHA384} and
+\texttt{DHE-RSA-AES256-GCM-SHA384}. To provide a decent level of security, all
+algorithms need to be safe (subject to the disclaimer in section
+\ref{section:disclaimer}).
Note: There are some very weak cipher suites in every crypto library, most of
them for historic reasons or due to legacy standards. The crypto export embargo
-is a good example\cite{Wikipedia:ExportCipher}.
-For the following chapter support of these low-security algorithms is disabled by setting
+is a good example\cite{Wikipedia:ExportCipher}. For the following chapter
+support of these low-security algorithms is disabled by setting
\texttt{!EXP:!LOW:!NULL} as part of the cipher string.
\todo{Team: do we need references for all cipher suites considered weak?}
\subsubsection{Key Exchange}
-Many algorithms allow secure key exchange. Among those are RSA, DH, EDH, ECDSA,
-ECDH, EECDH among others. During the key exchange, keys for authentication and for
-encryption are exchanged. %%For RSA and DSA those keys are the same. %% WHAT?
+Many algorithms allow secure key exchange. Those are RSA, DH, EDH, ECDSA,
+ECDH, EECDH amongst others During the key exchange, keys for authentication and
+for encryption are exchanged. %%For RSA and DSA those keys are the same. %%
+WHAT?
\todo{explain this section}
Secrecy'' and means that even recorded traffic cannot be decrypted later when someone
obtains the server key. \\
All ephemeral key exchange schemes are based on the Diffie-Hellman algorithm and require
-pre-generated Diffe-Hellman parameter (which allow fast ephemeral key generation). It
+pre-generated Diffie-Hellman parameter (which allow fast ephemeral key generation). It
is important to note that the Diffie-Hellman parameter settings need to reflect at least
the security (speaking in number of bits) as the RSA host key. \todo{TODO: reference!}
-\textbf{Elliptic Curves}\ref{section:EllipticCurveCryptography} required by current TLS
-standards only consist of the so-called NIST-curves (\texttt{secp256r1} and
-\texttt{secp384r1}) which may be weak because the parameters that led to their generation
-weren't properly explained (by the NSA)\cite{DJBSC}. \\
-Disabling support for Elliptic Curves leads to no ephemeral key exchange being available
-for the Windows platform. When you decide to use Elliptic Curves despite the uncertainty,
-make sure to at least use the stronger curve of the two supported by all clients
+\textbf{Elliptic Curves} (see section \ref{section:EllipticCurveCryptography})
+required by current TLS standards only consist of the so-called NIST-curves
+(\texttt{secp256r1} and \texttt{secp384r1}) which may be weak because the
+parameters that led to their generation weren't properly explained (by the
+NSA)\cite{DJBSC}. \\ Disabling support for Elliptic Curves leads to no
+ephemeral key exchange being available for the Windows platform. When you
+decide to use Elliptic Curves despite the uncertainty, make sure to at least
+use the stronger curve of the two supported by all clients
(\texttt{secp384r1}).
\subsubsection{Configuration B: Weaker ciphers, more compatability}
-In this section we propose a slightly weaker set of cipher suites.
-For example, there are some known weaknesses for the SHA-1 hash function that
-is included in this set. However, the advantage of this set of cipher suites
-is it's higher compatibility with a more diverse set of clients as well as
-less computational overhead.\\
+In this section we propose a slightly weaker set of cipher suites. For
+example, there are some known weaknesses for the SHA-1 hash function that is
+included in this set. The advantage of this set of cipher suites is not only
+the compatibility with a broad range of clients, but also less computational
+workload on the provisioning hardware.
+\\
\textbf{All further examples in this publication use Configuration B}.\\
"out of the box".
\begin{itemize}
-\item TLS1.2 is preferred over TLSv1.0/SSLv3 (while still providing a useable cipher
+\item TLSv1.2 is preferred over TLSv1.0/SSLv3 (while still providing a useable cipher
string for SSLv3).
\item AES256 and CAMELLIA256 count as very strong ciphers at the moment; preferrably in
GCM mode.\\
\todo{add a reference here please}
\item AES128 and CAMELLIA128 count as strong enough ciphers at the moment
\item DHE or ECDHE for forward secrecy
-\item RSA as this will fit most of todays setup
-\item AES256-SHA as a last ressort (with this cipher at the end, even systems with
+\item RSA as this will fit most of todays setups
+\item AES256-SHA as a last resort (with this cipher at the end, even systems with
very old versions of openssl like 0.9.8 will just work. Just forward secrecy
will not be used. On systems that do not support elliptic curves, that cipher
offers support for the Microsoft crypto libraries that only support ECDHE.
\item Specialized systems (such as medical devices, most embedded systems, etc.)
\item Wireless Access Points
\item Smart-cards/chip cards
-\item Advice on running a PKI or a CA.
+\item Advice on running a PKI or a CA
%\item Services which should be run only in an internal network and never face the Internet.
\end{itemize}
\begin{itemize}
\item For traditional asymmetric public-key cryptography we consider any key
-length below 2048 bits to be deprectated at the time of this writing (for long
+length below 2048 bits to be deprecated at the time of this writing (for long
term protection).
\item For elliptic curve cryptography we consider key lengths below 256 bits to
%%\subsection{IPMI, ILO and other lights out management solutions}
-We \textbf{strongly} recommend that any remote management system for servers such as ILO, iDRAC, IPMI based solutions and similar systems never be connected to the public internet.
+We \emph{strongly} recommend that any remote management system for servers such as ILO, iDRAC, IPMI based solutions and similar systems \emph{never} be connected to the public internet.
Consider creating an unrouted management VLAN and access that only via VPN.
\paragraph*{Exim string expansion}\mbox{}\\
-Note that most of the options accept expansion strings. This way you can eg. set cipher lists or STARTTLS advertisment conditionally. Please follow the link to the official Exim documentation to get more information.
+Note that most of the options accept expansion strings. This way you can eg. set cipher lists or STARTTLS advertisement conditionally. Please follow the link to the official Exim documentation to get more information.
\paragraph*{Limitations}\mbox{}\\
\end{lstlisting}
%% XXX FIXME: do we need to specify dhparams? Parameter: ssl_dhparam = file. See: http://wiki.nginx.org/HttpSslModule#ssl_protocols
+%% NO, use IETF/IKE
+
+If you absolutely want to specify your own DH parameters, you can specify them via
-It is recommended to specify your own Diffie-Hellman Parameters file of at least the same bit size as your RSA key. E.g. use no less than 2048bit DH parameters with a 2048bit RSA key.
\begin{lstlisting}[breaklines]
ssl_dhparam file;
\end{lstlisting}
+However, we advise you to read section \ref{section:DH} and stay with the standard IKE/IETF parameters (as long as they are $ > 1024 $ bits).
+
\item[Additional settings:]
git.bettercrypto.org / ach-master.git / commitdiff