minor typos in the \todo{} texts
[ach-master.git] / src / cipher_suites.tex
index 0f14db5..07c289d 100644 (file)
@@ -89,7 +89,7 @@ Win 7 and Win 8.1 crypto stack, Opera 17, OpenSSL $\ge$ 1.0.1e, Safari 6 / iOS
 \subsubsection{Configuration B: weaker ciphers, many clients}
 
 In this section we propose a slighly "weaker" set of cipher suites. There are
-some known weaknesses of for example SHA-1 which is included in this this set.
+some known weaknesses of for example SHA-1 which is included in this set.
 However, the advantage of this set of cipher suites is its wider compatibility
 with clients. 
 
@@ -102,6 +102,8 @@ We arrived at this set of cipher suites by selecting
 \begin{itemize}
 \item TLS 1.2, TLS 1.1, TLS 1.0
 \item allowing SHA-1
+\todo{AK: Note that SHA1 is considered broken but if we are in DHE, we might get around it as long as you can not calculate a SHA1 collision ``live'' on the wire}
+
 \end{itemize}
 
 This results in the string:
@@ -141,7 +143,7 @@ DH-parameter length limitation (1024 bit).
 \textbf{Explanation}
 
 For a detailed explanation of the cipher suites chosen, please see
-\ref{section:ChosingYourOwnCipherSuites}. In short, finding the perfect cipher
+\ref{section:ChoosingYourOwnCipherSuites}. In short, finding the perfect cipher
 string is impossible and must be a tradeoff. On the one hand
 there are mandatory and optional ciphers defined in a few RFCs, on the other hand
 there are clients and servers only implementing subsets of the specification.
@@ -171,10 +173,81 @@ by copy and paste and needs to just work.
 
 
 
+\subsection{Known insecure and weak cipher suites}
+\todo{PG: please write this section. List all known broken, obsolete, weak and insecure cipher suites . Or even better: find the best site which keeps track of outdated cipher suites and simply reference it. We do not want to maintain such a list ourselves!}
+
+\subsection{Compatibility}
+\todo{write this section. The idea here is to first document which server (and openssl) version we assumed. Once these parameters are fixed, we then list all clients which are supported for Variant A) and B). Therefore we can document compatibilities to some extent. The sysadmin can then choose roughly what he looses or gains by omitting certain cipher suites.}
+
+
+\subsection{Choosing your own cipher suites}
+\label{section:ChoosingYourOwnCipherSuites}
+
+\todo{ Adi...  you want to describe how to make your own selection of cipher suites here.}
+
+SSL/TLS cipher suites consist of a key exchange mechanism, an authentication, a
+stream cipher (or a block cipher with a chaining mode) and a message authentication
+mechanism.
+
+Many of those mechanisms are interchangeable like the key exchange 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 about every crypto library, most of
+them for historic reasons like the crypto export embargo
+\footnote{\url{http://en.wikipedia.org/wiki/Export_of_cryptography_in_the_United_States}}.
+For the following chapter support of those is assumed to be disabled by having
+\texttt{!EXP:!LOW:!NULL} as part of the cipher string.
+
+\todo{Adi: add boxes for summaries like here \\ \url{http://tex.stackexchange.com/questions/99809/box-or-sidebar-for-additional-text}}
+
+\todo{Team: do we need references for all cipher suites considered weak?}
+
+\subsubsection{key exchange}
+
+RSA, DSA, DH, EDH, ECDSA, ECDH, EECDH, FORTEZZA(?).
+
+Note that Elliptic Curves in current TLS standards (up to and including TLSv1.2) are
+questioned by many experts due to the lack of documentation on how the parameters
+specifying those curves were chosen. Without the EC mechanisms many clients, especially
+those using the Windows crypto libraries will not be able to use Forward Secrecy as these
+libraries only implement the elliptic curve variant of ephemeral DH key exchange. The
+curves in question are SECP256, SECP384, SECP521 and SECP571 of which the first two
+are the only ones implemented in the Windows crypto stack and they're the only listed
+as a requirement in the RFC. %%TODO: add link to RFC
+
+Other key exchange mechanisms like Pre-Shared Key (PSK) or Secure Remote Password
+(SRP) are irrelevant for regular SSL/TLS use. \texttt{!PSK:!SRP}
+
+\subsubsection{authentication}
+
+RSA, DSA, DSS, ECDSA, ECDH, FORTEZZA(?).
+
+Other authentication mechanisms like Pre Shared Keys aren't used in SSL/TLS: \texttt{!PSK:!aNULL}
+
+\subsubsection{encryption}
+
+AES, CAMELLIA, SEED, ARIA(?), FORTEZZA(?)...
+
+Other ciphers like IDEA, RC2, RC4, 3DES or DES are weak and therefor not recommended:
+\texttt{!DES:!3DES:!RC2:!RC4:!eNULL}
+
+\subsubsection{message authentication}
+
+SHA-1 (SHA), SHA-2 (SHA256, SHA384), AEAD
+
+Note that SHA-1 is considered broken and should not be used. SHA-1 is however a the
+only still available message authentication mechanism supporting TLS1.0/SSLv3. Without
+SHA-1 most clients will be locked out.
+
+Other hash functions like MD2, MD4 or MD5 are unsafe and broken: \texttt{!MD2:!MD4:!MD5}
+
+\subsubsection{combining cipher strings}
+%% reference 'man ciphers' and 'openssl ciphers' and show some simple examples
+%% VERY IMPORTANT: hint at the IANA-list and the differences in implementations
 
-\subsection{Chosing your own cipher suites}
-\label{section:ChosingYourOwnCipherSuites}
-\todo{ Adi...  you want to describe how to make your own selection of cipher suites here. The text below was simply the old text, still left here for reference.}
+\todo{ Adi...  The text below was simply the old text, still left here for reference.}
 
 %%% NOTE: we do not need to list this all here, can move to an appendix
 %At the time of this writing, SSL is defined in RFCs: