minor typos in the \todo{} texts
[ach-master.git] / src / cipher_suites.tex
index 63634c7..07c289d 100644 (file)
@@ -2,22 +2,22 @@
 
 Cipher suites are a combination of algorithms to provide for 
 Confidentiality, Integrity and Authenticity
-\footnote{url{http://en.wikipedia.org/wiki/Information\_security}} of 
+\footnote{\url{http://en.wikipedia.org/wiki/Information\_security}} of 
 communication. For example: sending encrypted data over the wire does not 
 ensure that the data can not be modified (message integrity), similarly
-encrypted data can be sent from an advesary. It is therefore paramount to
-proof that data has been sent from the desired source (message authenticity).
+encrypted data can be sent from an adversary. It is therefore paramount to
+prove that data has been sent from the desired source (message authenticity).
 This concept is known as authenticated encryption
-\footnote{url{http://en.wikipedia.org/wiki/Authenticated\_encryption}}
-\footnote{url{http://www.cs.jhu.edu/~astubble/dss/ae.pdf}}.
+\footnote{\url{http://en.wikipedia.org/wiki/Authenticated\_encryption}}
+\footnote{\url{http://www.cs.jhu.edu/~astubble/dss/ae.pdf}}.
 
 \subsection{Forward Secrecy}
 Forward Secrecy or Perfect Forward Secrecy is a property of a cipher suite 
 that ensures confidentiality even if the server key has been compromised.
-Thus if traffic has been recorded it can not be decrypted even if an advesary
+Thus if traffic has been recorded it can not be decrypted even if an adversary
 has got hold of the decryption key
-\footnote{url{http://en.wikipedia.org/wiki/Forward\_secrecy}}
-\footnote{urk{https://www.eff.org/deeplinks/2013/08/pushing-perfect-forward-secrecy-important-web-privacy-protection}}. 
+\footnote{\url{http://en.wikipedia.org/wiki/Forward\_secrecy}}
+\footnote{\url{https://www.eff.org/deeplinks/2013/08/pushing-perfect-forward-secrecy-important-web-privacy-protection}}. 
 
 \subsection{Recommended cipher suites}
 
@@ -29,7 +29,7 @@ tool to test out different settings. The authors used ssllabs.com to arrive at
 a set of cipher suites which we will recommend throught this document.
 \textbf{Caution: these settings can only represent a subjective choice of the
 authors at the time of this writing. It might be a wise choice to select your
-own ciper suites based on the instructions in section
+own cipher suites based on the instructions in section
 \ref{section:ChosingYourOwnCipherSuites}}.
 
 
@@ -66,20 +66,21 @@ This results in the string:
 
 
 \begin{center}
+
 \begin{tabular}{| l | l | l | l | l| l | l |}
 \hline
 ID        & OpenSSL name                & Version & KeyEx & Auth & Cipher & Hash \\ \hline
-0xC030 & ECDHE-RSA-AES256-GCM-SHA384 & TLSv1.2 & ECDH  &  RSA &AESGCM(256)  & AEAD   \\ \hline
-0xC028 & ECDHE-RSA-AES256-SHA384     & TLSv1.2 & ECDH  &  RSA &AES(256)     & SHA384 \\ \hline
-0x009F & DHE-RSA-AES256-GCM-SHA384   & TLSv1.2 & DH    &  RSA &AESGCM(256)  & AEAD   \\ \hline
-0x006B & DHE-RSA-AES256-SHA256       & TLSv1.2 & DH    &  RSA &AES(256)     & SHA256 \\ \hline
+\verb|0xC030| & ECDHE-RSA-AES256-GCM-SHA384 & TLSv1.2 & ECDH  &  RSA &AESGCM(256)  & AEAD   \\ \hline
+\verb|0xC028| & ECDHE-RSA-AES256-SHA384     & TLSv1.2 & ECDH  &  RSA &AES(256)     & SHA384 \\ \hline
+\verb|0x009F| & DHE-RSA-AES256-GCM-SHA384   & TLSv1.2 & DH    &  RSA &AESGCM(256)  & AEAD   \\ \hline
+\verb|0x006B| & DHE-RSA-AES256-SHA256       & TLSv1.2 & DH    &  RSA &AES(256)     & SHA256 \\ \hline
 \end{tabular}
 \end{center}
 
 
 \textbf{Compatibility}
 
-Only clients which support TLS1.2 are covered by this cipher suites (Chrome 30,
+Only clients which support TLS1.2 are covered by these cipher suites (Chrome 30,
 Win 7 and Win 8.1 crypto stack, Opera 17, OpenSSL $\ge$ 1.0.1e, Safari 6 / iOS
 6.0.1, Safari 7 / OS X 10.9).
 
@@ -88,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. 
 
@@ -101,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:
@@ -129,22 +132,24 @@ ID        & OpenSSL name                      & Version & KeyEx & Auth & Cipher & Hash \\ \hlin
 
 \textbf{Compatibility}
 
-Note that this cipher suites will not work with anything using Windows XP's
+Note that these cipher suites will not work with anything using Windows XP's
 crypto stack (IE, Outlook), Java 6, Java 7 and Android 2.3. Java 7 could be
 made compatible by installing the "Java Cryptography Extension (JCE) Unlimited
-Strength Jurisdiction Policy Files" (JCE). We could not verify yet if
-installing JCE also fixes the Java 7 DH-parameter length limitation (1024 bit). 
+Strength Jurisdiction Policy Files"
+(JCE) \footnote{\url{http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html}}.
+We could not verify yet if installing JCE also fixes the Java 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 mandatory and optional ciphers defined in a few RFCs, on the other hand
 there are clients and servers only implementing subsets of the specification.
 
 Straight forward, we wanted strong ciphers, forward secrecy
-\footnote{url{http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forward.html}}
+\footnote{\url{http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forward.html}}
 and the most clients we could get while still having a cipher string that can be
 used on older servers too (think OpenSSL 0.9.8). This cipher string is meant to be used
 by copy and paste and needs to just work.
@@ -168,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:  
@@ -239,7 +315,7 @@ Following Ivan Ristic's adivce we arrived at a categorisation of cipher suites.
 \end{tabular}
 \end{center}
 
-A remark on the ``consider'' section: the BSI (Federal office for information security, Germany) recommends in its technical report TR-02102-2\footnote{\url{https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2_pdf.html}} to \textbf{avoid} non-ephemeral\footnote{ephemeral keys are session keys which are destroyed upon termination of the encrypted session. In TLS/SSL, they are realized by the DHE cipher suites. } keys for any communication which might contain personal or sensitive data. In this document, we follow BSI's advice and therefore only keep cipher suites containing (EC)DH\textbf{E} (ephemeral) variants. System administrators, who can not use forward secrecy can still use the cipher suites in the ``consider'' section. We however, do not recommend them in this document.
+A remark on the ``consider'' section: the BSI (Federal office for information security, Germany) recommends in its technical report TR-02102-2\footnote{\url{https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2_pdf.html}} to \textbf{avoid} non-ephemeral\footnote{Ephemeral keys are session keys which are destroyed upon termination of the encrypted session. In TLS/SSL, they are realized by the DHE cipher suites. } keys for any communication which might contain personal or sensitive data. In this document, we follow BSI's advice and therefore only keep cipher suites containing (EC)DH\textbf{E} (ephemeral) variants. System administrators, who can not use forward secrecy can still use the cipher suites in the ``consider'' section. We however, do not recommend them in this document.
 
 %% NOTE: s/forward secrecy/perfect forward secrecy???