move theory sections into theory subdir
authorAaron Kaplan <aaron@lo-res.org>
Mon, 23 Dec 2013 19:31:45 +0000 (20:31 +0100)
committerAaron Kaplan <aaron@lo-res.org>
Mon, 23 Dec 2013 19:31:45 +0000 (20:31 +0100)
14 files changed:
src/cipher_suites.tex [deleted file]
src/cipher_suites/architecture.tex [deleted file]
src/cipher_suites/choosing.tex [deleted file]
src/cipher_suites/compatibility.tex [deleted file]
src/cipher_suites/forward.tex [deleted file]
src/cipher_suites/insecure.tex [deleted file]
src/cipher_suites/recommended.tex [deleted file]
src/theory/cipher_suites.tex [new file with mode: 0644]
src/theory/cipher_suites/architecture.tex [new file with mode: 0644]
src/theory/cipher_suites/choosing.tex [new file with mode: 0644]
src/theory/cipher_suites/compatibility.tex [new file with mode: 0644]
src/theory/cipher_suites/forward.tex [new file with mode: 0644]
src/theory/cipher_suites/insecure.tex [new file with mode: 0644]
src/theory/cipher_suites/recommended.tex [new file with mode: 0644]

diff --git a/src/cipher_suites.tex b/src/cipher_suites.tex
deleted file mode 100644 (file)
index a03e33f..0000000
+++ /dev/null
@@ -1,34 +0,0 @@
-
-\section{Cipher suites}
-\label{section:CipherSuites}
-\todo{team: section \ref{section:CipherSuites} is currently a bit messy. Re-do it}
-
-
-\subsection{Architectural overview }
-\label{subsection:architecture}
-\input{"./cipher_suites/architecture.tex"}
-
-
-\subsection{Forward Secrecy}
-\label{subsection:PFS}
-\input{"./cipher_suites/forward.tex"}
-
-
-\subsection{Recommended cipher suites}
-\label{section:recommendedciphers}
-\input{"./cipher_suites/recommended.tex"}
-
-
-%\subsection{Known insecure and weak cipher suites}
-%\input{"./cipher_suites/insecure.tex"}
-
-
-\subsection{Compatibility}
-\label{subsection:compatibility}
-\input{"./cipher_suites/compatibility.tex"}
-
-
-\subsection{Choosing your own cipher suites}
-\label{section:ChoosingYourOwnCipherSuites}
-\input{"./cipher_suites/choosing.tex"}
-
diff --git a/src/cipher_suites/architecture.tex b/src/cipher_suites/architecture.tex
deleted file mode 100644 (file)
index e4e8bca..0000000
+++ /dev/null
@@ -1,54 +0,0 @@
-%%\subsection{Architectural overview }
-
-This section defines some terms which will be used throughout this guide.
-
-
-A cipher suite is a standardised collection of key exchange algorithms, encryption 
-algorithms (ciphers) and Message authentication codes (MAC) algortihm that provides
-authenticated encryption schemes. It consists of the following components:
-
-\begin{description}
-
-\item{\it Key exchange protocol:}
-``An (interactive) key exchange protocol is a method whereby parties who do not 
-share any secret information can generate a shared, secret key by communicating 
-over a public channel. The main property guaranteed here is that an 
-eavesdropping adversary who sees all the messages sent over the communication 
-line does not learn anything about the resulting secret key.'' \cite{katz2008introduction}
-
-Example: \texttt{DHE}
-
-\item{\it Authentication:}
-The client authenticates the server by its certificate. Optionally the server 
-may authenticate the client certificate.
-
-Example: \texttt{RSA}
-
-\item{\it Cipher:}
-The cipher is used to encrypt the message stream. It also contains the key size
-and mode used by the suite.
-
-Example: \texttt{AES256}
-
-\item{\it Message authentication code (MAC):}
-A MAC ensures that the message has not been tampered with (integrity).
-
-Examples: \texttt{SHA256}
-
-\item{\it Authenticated Encryption with Associated Data (AEAD):}
-AEAD is a class of authenticated encryption block-cipher modes
-which take care of encryption as well as authentication (e.g. GCM, CCM mode). 
-
-Example: \texttt{AES256-GCM}
-
-
-
-\begin{figure}[h]
-\makebox[\textwidth]{
-\framebox[1.1\width]{ \texttt{DHE} }--\framebox[1.1\width]{ \texttt{RSA} }--\framebox[1.1\width]{ \texttt{AES256} }--\framebox[1.1\width]{ \texttt{SHA256} } }
-\caption{Composition of a typical cipher string}
-\end{figure}
-
-\item {\textbf{A note on nomenclature:}} there are two common naming schemes for cipher strings -- IANA names (see section \ref{section:Links}) and the more well known OpenSSL names. In this document we will always use OpenSSL names unless a specific service uses IANA names.
-
-\end{description}
diff --git a/src/cipher_suites/choosing.tex b/src/cipher_suites/choosing.tex
deleted file mode 100644 (file)
index b31a23b..0000000
+++ /dev/null
@@ -1,248 +0,0 @@
-%%\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 algorithm, an authentication, a
-%%stream cipher (or a block cipher with a chaining mode) and a message authentication
-%%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}).
-
-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
-\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.  Those are RSA, DH, EDH, ECDSA,
-ECDH, EECDH amongst others. During the key exchange, keys used for authentication
-and symmetric encryption are exchanged. For RSA, DSA and ECDSA those keys are derived
-from the server's public key.
-
-\todo{explain this section}
-
-\begin{center}
-\begin{tabular}{llll}
-    \toprule
-          & \textbf{Key}  & \textbf{EC}  & \textbf{ephemeral} \\ \cmidrule(lr){1-4}
-   RSA    & RSA           & no           & no                 \\
-   DH     & RSA           & no           & no                 \\
-   EDH    & RSA           & no           & yes                \\
-   ECDH   & both          & yes          & no                 \\
-   EECDH  & both          & yes          & yes                \\
-   DSA    & DSA           & no           & no                 \\
-   ECDSA  & DSA           & yes          & no                 \\
-\bottomrule
-\end{tabular}
-%\\
-%\\
-%disabled: \texttt{!PSK:!SRP}
-\end{center}
-
-\textbf{Ephemeral Key Exchange} uses different keys for authentication (the server's RSA
-key) and encryption (a randomly created key). This advantage is called ``Forward
-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 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} (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
-authors\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}).
-
-
-Other key exchange mechanisms like Pre-Shared Key (PSK) are irrelevant for
-regular SSL/TLS use.
-
-\subsubsection{Authentication}
-
-RSA, DSA, DSS, ECDSA, ECDH
-
-During Key Exchange the server proved that he is in control of the private key
-associated with a certain public key (the server's certificate). The client
-verifies the server's identity by comparing the signature on the certificate
-and matching it with its trust database. For details about the trust model of
-SSL/TLS please see \ref{section:PKIs}.
-
-In addition to the server providing its identity, a client might do so as well.
-That way mutual trust can be established. Another mechanism providing client
-authentication is Secure Remote Password (SRP)\todo{reference}. All those
-mechanisms require special configuration.
-
-Other authentication mechanisms like Pre Shared Keys aren't used in SSL/TLS.
-Anonymous sessions will not be discussed in this paper.
-
-\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 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
-
-\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:  
-%
-%\begin{itemize}
-%\item RFC2246 - TLS1.0                
-%\item RFC3268 - AES           
-%\item RFC4132 - Camelia               
-%\item RFC4162 - SEED          
-%\item RFC4279 - PSK           
-%\item RFC4346 - TLS 1.1               
-%\item RFC4492 - ECC           
-%\item RFC4785 - PSK\_NULL             
-%\item RFC5246 - TLS 1.2               
-%\item RFC5288 - AES\_GCM              
-%\item RFC5289 - AES\_GCM\_SHA2\_ECC           
-%\item RFC5430 - Suite B               
-%\item RFC5487 - GCM\_PSK              
-%\item RFC5489 - ECDHE\_PSK            
-%\item RFC5932 - Camelia               
-%\item RFC6101 - SSL 3.0               
-%\item RFC6209 - ARIA          
-%\item RFC6367 - Camelia               
-%\item RFC6655 - AES\_CCM              
-%\item RFC7027 - Brainpool Curves              
-%\end{itemize}
-
-%\subsubsection{Overview of SSL Server settings}
-%
-%
-%Most Server software (Webservers, Mail servers, etc.) can be configured to prefer certain cipher suites over others. 
-%We followed the recommendations by Ivan Ristic's SSL/TLS Deployment Best Practices\footnote{\url{https://www.ssllabs.com/projects/best-practices/index.html}} document (see section 2.2 "Use Secure Protocols") and arrived at a list of recommended cipher suites for SSL enabled servers.
-%
-%Following Ivan Ristic's adivce we arrived at a categorisation of cipher suites.
-%
-%\begin{center}
-%\begin{tabular}{lllll}
-%\cmidrule[\heavyrulewidth]{2-5}
-%& \textbf{Version}   & \textbf{KeyEx} & \textbf{Cipher}    & \textbf{MAC}       \\\cmidrule(lr){2-5}
-%\cellcolor{green}prefer  & TLS 1.2   & DHE\_DSS   & AES\_256\_GCM   & SHA384        \\
-%    &   & DHE\_RSA   & AES\_256\_CCM   & SHA256        \\
-%    &   & ECDHE\_ECDSA   & AES\_256\_CBC   &       \\
-%    &   & ECDHE\_RSA &   &       \\ 
-%    &   &   &   &       \\
-%\cellcolor{orange}consider    & TLS 1.1   & DH\_DSS    & AES\_128\_GCM   & SHA       \\
-%    & TLS 1.0   & DH\_RSA    & AES\_128\_CCM   &       \\
-%    &   & ECDH\_ECDSA    & AES\_128\_CBC   &       \\ 
-%    &   & ECDH\_RSA  & CAMELLIA\_256\_CBC  &       \\
-%    &   & RSA   & CAMELLIA\_128\_CBC  &       \\
-%    &   &   &   &       \\
-%\cellcolor{red}avoid   
-%& SSL 3.0   & NULL  & NULL  & NULL      \\
-%    &   & DH\_anon   & RC4\_128   & MD5       \\
-%    &   & ECDH\_anon & 3DES\_EDE\_CBC  &       \\
-%    &   &   & DES\_CBC   &       \\
-%    &   &   &   &       \\
-%\cellcolor{blue}{\color{white}special }
-%&   & PSK   & CAMELLIA\_256\_GCM  &       \\
-%    &   & DHE\_PSK   & CAMELLIA\_128\_GCM  &       \\
-%    &   & RSA\_PSK   & ARIA\_256\_GCM  &       \\
-%    &   & ECDHE\_PSK & ARIA\_256\_CBC  &       \\
-%    &   &   & ARIA\_128\_GCM  &       \\
-%    &   &   & ARIA\_128\_CBC  &       \\
-%    &   &   & SEED  &       \\
-%\cmidrule[\heavyrulewidth]{2-5}
-%\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.
-%
-%%% NOTE: s/forward secrecy/perfect forward secrecy???
-%
-%Note that the entries marked as ``special'' are cipher suites which are not common to all clients (webbrowsers etc).
-%
-%
-%\subsubsection{Tested clients}
-% 
-%Next we tested the cipher suites above on the following clients:
-%
-%%% NOTE: we need to test with more systems!!
-%\begin{itemize}
-%\item Chrome 30.0.1599.101 Mac OS X 10.9
-%\item Safari 7.0 Mac OS X 10.9
-%\item Firefox 25.0 Mac OS X 10.9
-%\item Internet Explorer 10 Windows 7
-%\item Apple iOS 7.0.3
-%\end{itemize}
-%
-%
-%The result of testing the cipher suites with these clients gives us a preference order as shown in table \ref{table:prefOrderCipherSuites}. 
-%Should a client not be able to use a specific cipher suite, it will fall back to the next possible entry as given by the ordering.
-%
-%\begin{table}[h]
-%\centering\small
-%    \begin{tabular}{cllcccc}
-%    \toprule
-%    \textbf{Pref}   & \textbf{Cipher Suite}                            & \textbf{ID}   & \multicolumn{4}{l}{\textbf{Supported by}}\\ 
-%    \cmidrule(lr){4-7}
-%                    & \textbf{OpenSSL Name}                            &               & Chrome & FF   & IE   & Safari \\
-%    \cmidrule(lr){1-7}
-%    \phantom{0}1    & \verb|TLS_DHE_RSA_WITH_AES_256_GCM_SHA384|     & \verb|0x009f| & \no    & \no  & \no  & \no    \\
-%                    & \verb|DHE-RSA-AES256-GCM-SHA384|                      &               & &&&\\\rowcolor{lightlightgray}
-%    \phantom{0}2    & \verb|TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384| & \verb|0xC024| & \no    & \no  & \no  & \yes   \\\rowcolor{lightlightgray}
-%                    & \verb|ECDHE-ECDSA-AES256-SHA384|                      &               & &&&\\
-%    \phantom{0}3    & \verb|TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384|   & \verb|0xC028| & \no    & \no  & \no  & \yes   \\
-%                    & \verb|ECDHE-RSA-AES256-SHA384|                        &               & &&&\\\rowcolor{lightlightgray}
-%    \phantom{0}4    & \verb|TLS_DHE_RSA_WITH_AES_256_CBC_SHA256|     & \verb|0x006B| & \yes   & \no  & \no  & \yes   \\\rowcolor{lightlightgray}
-%                    & \verb|DHE-RSA-AES256-SHA256|                          &               & &&&\\
-%    \phantom{0}5    & \verb|TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA|    & \verb|0xC00A| & \yes   & \yes & \yes & \yes   \\
-%                    & \verb|ECDHE-ECDSA-AES256-SHA|                         &               & &&&\\\rowcolor{lightlightgray}
-%    \phantom{0}6    & \verb|TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA|      & \verb|0xC014| & \yes   & \yes & \yes & \yes   \\\rowcolor{lightlightgray}
-%                    & \verb|ECDHE-RSA-AES256-SHA|                           &               & &&&\\
-%    \phantom{0}7    & \verb|TLS_DHE_RSA_WITH_AES_256_CBC_SHA|        & \verb|0x0039| & \yes   & \yes & \no  & \yes   \\
-%                    & \verb|DHE-RSA-AES256-SHA|                             &               & &&&\\\rowcolor{lightlightgray}
-%    \phantom{0}8    & \verb|TLS_DHE_DSS_WITH_AES_256_CBC_SHA|        & \verb|0x0038| & \no    & \yes & \yes & \no    \\\rowcolor{lightlightgray}
-%                    & \verb|DHE-DSS-AES256-SHA|                             &               & &&&\\
-%    \phantom{0}9    & \verb|TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA|   & \verb|0x0088| & \no    & \yes & \no  & \no    \\
-%                    & \verb|DHE-RSA-CAMELLIA256-SHA|                        &               & &&&\\\rowcolor{lightlightgray}
-%    \phantom{}10    & \verb|TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA|   & \verb|0x0087| & \no    & \yes & \no  & \no    \\\rowcolor{lightlightgray}
-%                    & \verb|DHE-DSS-CAMELLIA256-SHA|                        &               & &&&\\
-%   \bottomrule
-%    \end{tabular}
-%\caption{Preference order of cipher suites.  All suites are supported by OpenSSL.}
-%\label{table:prefOrderCipherSuites}
-%\end{table}
-%
-%Note: the above table \ref{table:prefOrderCipherSuites} contains Elliptic curve key exchanges. There are currently strong doubts\footnote{\url{http://safecurves.cr.yp.to/rigid.html}} concerning ECC.
-%If unsure, remove the cipher suites starting with ECDHE in the table above.
-%
-%
-%Based on this ordering, we can now define the corresponding settings for servers. We will start with the most common web servers.
diff --git a/src/cipher_suites/compatibility.tex b/src/cipher_suites/compatibility.tex
deleted file mode 100644 (file)
index d8621fd..0000000
+++ /dev/null
@@ -1,2 +0,0 @@
-%%\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.}
\ No newline at end of file
diff --git a/src/cipher_suites/forward.tex b/src/cipher_suites/forward.tex
deleted file mode 100644 (file)
index e7a9ab6..0000000
+++ /dev/null
@@ -1,8 +0,0 @@
-%%\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 adversary
-has got hold of the server key
-\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}}
-\footnote{\url{http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html}}.
diff --git a/src/cipher_suites/insecure.tex b/src/cipher_suites/insecure.tex
deleted file mode 100644 (file)
index 585af09..0000000
+++ /dev/null
@@ -1,17 +0,0 @@
-%%\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!}
-
-%%Ciphers with 112bit or less are considered weak and aren't recommended. Note that \texttt{3DES} provides only 112bit of security \footnote{\url{http://csrc.nist.gov/publications/PubsSPs.html\#800-57-part1}}.
-
-%% comment Florian:
-%% Please do not consider ciphers with a 112 bit key as weak. I think it is
-%% fine to do not recommend 3DES, but we should not claim that it is weak.
-%% In particular, 3DES with an effective keysize of 112 bits is still
-%% recommended by NIST and by ECRYPT2 for medium-term protection until 2030.
-
-
-%One special remark is necessary for 3DES: here we want to note
-%that it theoretically has 168 bit security, however based on the NIST Special
-%Publication 800-57
-%\footnote{\url{http://csrc.nist.gov/publications/PubsSPs.html\#800-57-part1},
-%pages 63 and 64}, it is clear that 3DES is only considered 80 bits / 112 bits.
diff --git a/src/cipher_suites/recommended.tex b/src/cipher_suites/recommended.tex
deleted file mode 100644 (file)
index dd84b85..0000000
+++ /dev/null
@@ -1,166 +0,0 @@
-%%\subsection{Recommended cipher suites}
-
-In principle system administrators who want to improve their communication security
-have to make a difficult decision between effectively locking out some users and 
-keeping high cipher suite security while supporting as many users as possible.
-The website \url{https://www.ssllabs.com/} gives administrators and security engineers
-a tool to test their setup and compare compatibility with clients. The authors made 
-use of ssllabs.com to arrive at a set of cipher suites which we will recommend 
-throughout this document.\\
-
-\textbf{Caution: these settings can only represent a subjective
-choice of the authors at the time of writing. It might be a wise choice to
-select your own and review cipher suites based on the instructions in section
-\ref{section:ChoosingYourOwnCipherSuites}}.
-
-
-\subsubsection{Configuration A: Strong ciphers, fewer clients}
-
-At the time of writing we recommend the following set of strong cipher
-suites which may be useful in an environment where one does not depend on many,
-different clients and where compatibility is not a big issue.  An example
-of such an environment might be machine-to-machine communication or corporate
-deployments where software that is to be used can be defined freely.
-
-
-We arrived at this set of cipher suites by selecting:
-
-\begin{itemize}
-\item TLS 1.2
-\item Perfect forward secrecy / ephemeral Diffie Hellman
-\item strong MACs (SHA-2) or
-\item GCM as Authenticated Encryption scheme
-\end{itemize}
-
-This results in the OpenSSL string:
-
-\begin{lstlisting}[breaklines]
-'EDH+aRSA+AES256:EECDH+aRSA+AES256:!SSLv3'
-\end{lstlisting}
-
-%$\implies$ resolves to 
-%
-%\begin{verbatim}
-%openssl ciphers -V $string
-%\end{verbatim}
-
-
-
-%\todo{make a column for cipher chaining mode} --> not really important, is it?
-\begin{center}
-
-\begin{tabular}{lllllll}
-\toprule
-\textbf{ID}   & \textbf{OpenSSL Name}       & \textbf{Version} & \textbf{KeyEx} & \textbf{Auth} & \textbf{Cipher} & \textbf{MAC}\\\cmidrule(lr){1-7}
-\verb|0x009F| & DHE-RSA-AES256-GCM-SHA384   & TLSv1.2          & DH             &  RSA          & AESGCM(256)     & AEAD         \\
-\verb|0x006B| & DHE-RSA-AES256-SHA256       & TLSv1.2          & DH             &  RSA          & AES(256) (CBC)  & SHA256       \\
-\verb|0xC030| & ECDHE-RSA-AES256-GCM-SHA384 & TLSv1.2          & ECDH           &  RSA          & AESGCM(256)     & AEAD         \\
-\verb|0xC028| & ECDHE-RSA-AES256-SHA384     & TLSv1.2          & ECDH           &  RSA          & AES(256) (CBC)  & SHA384       \\
-\bottomrule
-\end{tabular}
-\end{center}
-
-
-\textbf{Compatibility}
-
-Only clients which support TLS 1.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).
-
-
-
-\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.  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}.\\
-
-We arrived at this set of cipher suites by selecting:
-
-\begin{itemize}
-\item TLS 1.2, TLS 1.1, TLS 1.0
-\item allow 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 OpenSSL string:
-
-\begin{lstlisting}[breaklines]
-'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA'
-\end{lstlisting}
-
-\todo{make a column for cipher chaining mode}
-\begin{center}
-\begin{tabular}{lllllll}
-\toprule
-\textbf{ID}   & \textbf{OpenSSL Name}       & \textbf{Version} & \textbf{KeyEx} & \textbf{Auth} & \textbf{Cipher} & \textbf{MAC}\\\cmidrule(lr){1-7}
-\verb|0x009F| & DHE-RSA-AES256-GCM-SHA384   & TLSv1.2          & DH             & RSA           & AESGCM(256)     & AEAD         \\
-\verb|0x006B| & DHE-RSA-AES256-SHA256       & TLSv1.2          & DH             & RSA           & AES(256)        & SHA256       \\
-\verb|0xC030| & ECDHE-RSA-AES256-GCM-SHA384 & TLSv1.2          & ECDH           & RSA           & AESGCM(256)     & AEAD         \\
-\verb|0xC028| & ECDHE-RSA-AES256-SHA384     & TLSv1.2          & ECDH           & RSA           & AES(256)        & SHA384       \\
-\verb|0x009E| & DHE-RSA-AES128-GCM-SHA256   & TLSv1.2          & DH             & RSA           & AESGCM(128)     & AEAD         \\
-\verb|0x0067| & DHE-RSA-AES128-SHA256       & TLSv1.2          & DH             & RSA           & AES(128)        & SHA256       \\
-\verb|0xC02F| & ECDHE-RSA-AES128-GCM-SHA256 & TLSv1.2          & ECDH           & RSA           & AESGCM(128)     & AEAD         \\
-\verb|0xC027| & ECDHE-RSA-AES128-SHA256     & TLSv1.2          & ECDH           & RSA           & AES(128)        & SHA256       \\
-\verb|0x0088| & DHE-RSA-CAMELLIA256-SHA     & SSLv3            & DH             & RSA           & Camellia(256)   & SHA1         \\
-\verb|0x0039| & DHE-RSA-AES256-SHA          & SSLv3            & DH             & RSA           & AES(256)        & SHA1         \\
-\verb|0xC014| & ECDHE-RSA-AES256-SHA        & SSLv3            & ECDH           & RSA           & AES(256)        & SHA1         \\
-\verb|0x0045| & DHE-RSA-CAMELLIA128-SHA     & SSLv3            & DH             & RSA           & Camellia(128)   & SHA1         \\
-\verb|0x0033| & DHE-RSA-AES128-SHA          & SSLv3            & DH             & RSA           & AES(128)        & SHA1         \\
-\verb|0xC013| & ECDHE-RSA-AES128-SHA        & SSLv3            & ECDH           & RSA           & AES(128)        & SHA1         \\
-\verb|0x0084| & CAMELLIA256-SHA             & SSLv3            & RSA            & RSA           & Camellia(256)   & SHA1         \\
-\verb|0x0035| & AES256-SHA                  & SSLv3            & RSA            & RSA           & AES(256)        & SHA1         \\
-\verb|0x0041| & CAMELLIA128-SHA             & SSLv3            & RSA            & RSA           & Camellia(128)   & SHA1         \\
-\verb|0x002F| & AES128-SHA                  & SSLv3            & RSA            & RSA           & AES(128)        & SHA1         \\
-\bottomrule
-\end{tabular}
-\end{center}
-
-\textbf{Compatibility}
-
-Note that these cipher suites will not work with Windows XP's crypto stack (e.g. 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) \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). 
-\todo{do that!}
-
-\textbf{Explanation}
-
-For a detailed explanation of the cipher suites chosen, please see
-\ref{section:ChoosingYourOwnCipherSuites}. In short, finding the perfect cipher
-string is impossible and must be a tradeoff between compatibility and security. 
-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.
-
-Straight forward, the authors wanted strong ciphers, forward secrecy
-\footnote{\url{http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forward.html}}
-and the best client compatibility possible while still ensuring a cipher string that can be
-used on legacy installations (e.g. OpenSSL 0.9.8). 
-
-Our recommended cipher strings are meant to be used via copy and paste and need to work
-"out of the box".
-
-\begin{itemize}
-\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.
-\item AES128 and CAMELLIA128 count as strong ciphers at the moment
-\item DHE or ECDHE for forward secrecy
-\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
-      legacy distributions of OpenSSL will work out of the box. Forward secrecy
-      will not be available. On systems that do not support elliptic curves, that cipher
-      offers support for the Microsoft crypto libraries that only support ECDHE. \todo{what does that mean?! inconclusive!}
-\end{itemize}
-
-\todo{Adi: review "justification" when next section is written}
diff --git a/src/theory/cipher_suites.tex b/src/theory/cipher_suites.tex
new file mode 100644 (file)
index 0000000..a03e33f
--- /dev/null
@@ -0,0 +1,34 @@
+
+\section{Cipher suites}
+\label{section:CipherSuites}
+\todo{team: section \ref{section:CipherSuites} is currently a bit messy. Re-do it}
+
+
+\subsection{Architectural overview }
+\label{subsection:architecture}
+\input{"./cipher_suites/architecture.tex"}
+
+
+\subsection{Forward Secrecy}
+\label{subsection:PFS}
+\input{"./cipher_suites/forward.tex"}
+
+
+\subsection{Recommended cipher suites}
+\label{section:recommendedciphers}
+\input{"./cipher_suites/recommended.tex"}
+
+
+%\subsection{Known insecure and weak cipher suites}
+%\input{"./cipher_suites/insecure.tex"}
+
+
+\subsection{Compatibility}
+\label{subsection:compatibility}
+\input{"./cipher_suites/compatibility.tex"}
+
+
+\subsection{Choosing your own cipher suites}
+\label{section:ChoosingYourOwnCipherSuites}
+\input{"./cipher_suites/choosing.tex"}
+
diff --git a/src/theory/cipher_suites/architecture.tex b/src/theory/cipher_suites/architecture.tex
new file mode 100644 (file)
index 0000000..e4e8bca
--- /dev/null
@@ -0,0 +1,54 @@
+%%\subsection{Architectural overview }
+
+This section defines some terms which will be used throughout this guide.
+
+
+A cipher suite is a standardised collection of key exchange algorithms, encryption 
+algorithms (ciphers) and Message authentication codes (MAC) algortihm that provides
+authenticated encryption schemes. It consists of the following components:
+
+\begin{description}
+
+\item{\it Key exchange protocol:}
+``An (interactive) key exchange protocol is a method whereby parties who do not 
+share any secret information can generate a shared, secret key by communicating 
+over a public channel. The main property guaranteed here is that an 
+eavesdropping adversary who sees all the messages sent over the communication 
+line does not learn anything about the resulting secret key.'' \cite{katz2008introduction}
+
+Example: \texttt{DHE}
+
+\item{\it Authentication:}
+The client authenticates the server by its certificate. Optionally the server 
+may authenticate the client certificate.
+
+Example: \texttt{RSA}
+
+\item{\it Cipher:}
+The cipher is used to encrypt the message stream. It also contains the key size
+and mode used by the suite.
+
+Example: \texttt{AES256}
+
+\item{\it Message authentication code (MAC):}
+A MAC ensures that the message has not been tampered with (integrity).
+
+Examples: \texttt{SHA256}
+
+\item{\it Authenticated Encryption with Associated Data (AEAD):}
+AEAD is a class of authenticated encryption block-cipher modes
+which take care of encryption as well as authentication (e.g. GCM, CCM mode). 
+
+Example: \texttt{AES256-GCM}
+
+
+
+\begin{figure}[h]
+\makebox[\textwidth]{
+\framebox[1.1\width]{ \texttt{DHE} }--\framebox[1.1\width]{ \texttt{RSA} }--\framebox[1.1\width]{ \texttt{AES256} }--\framebox[1.1\width]{ \texttt{SHA256} } }
+\caption{Composition of a typical cipher string}
+\end{figure}
+
+\item {\textbf{A note on nomenclature:}} there are two common naming schemes for cipher strings -- IANA names (see section \ref{section:Links}) and the more well known OpenSSL names. In this document we will always use OpenSSL names unless a specific service uses IANA names.
+
+\end{description}
diff --git a/src/theory/cipher_suites/choosing.tex b/src/theory/cipher_suites/choosing.tex
new file mode 100644 (file)
index 0000000..b31a23b
--- /dev/null
@@ -0,0 +1,248 @@
+%%\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 algorithm, an authentication, a
+%%stream cipher (or a block cipher with a chaining mode) and a message authentication
+%%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}).
+
+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
+\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.  Those are RSA, DH, EDH, ECDSA,
+ECDH, EECDH amongst others. During the key exchange, keys used for authentication
+and symmetric encryption are exchanged. For RSA, DSA and ECDSA those keys are derived
+from the server's public key.
+
+\todo{explain this section}
+
+\begin{center}
+\begin{tabular}{llll}
+    \toprule
+          & \textbf{Key}  & \textbf{EC}  & \textbf{ephemeral} \\ \cmidrule(lr){1-4}
+   RSA    & RSA           & no           & no                 \\
+   DH     & RSA           & no           & no                 \\
+   EDH    & RSA           & no           & yes                \\
+   ECDH   & both          & yes          & no                 \\
+   EECDH  & both          & yes          & yes                \\
+   DSA    & DSA           & no           & no                 \\
+   ECDSA  & DSA           & yes          & no                 \\
+\bottomrule
+\end{tabular}
+%\\
+%\\
+%disabled: \texttt{!PSK:!SRP}
+\end{center}
+
+\textbf{Ephemeral Key Exchange} uses different keys for authentication (the server's RSA
+key) and encryption (a randomly created key). This advantage is called ``Forward
+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 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} (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
+authors\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}).
+
+
+Other key exchange mechanisms like Pre-Shared Key (PSK) are irrelevant for
+regular SSL/TLS use.
+
+\subsubsection{Authentication}
+
+RSA, DSA, DSS, ECDSA, ECDH
+
+During Key Exchange the server proved that he is in control of the private key
+associated with a certain public key (the server's certificate). The client
+verifies the server's identity by comparing the signature on the certificate
+and matching it with its trust database. For details about the trust model of
+SSL/TLS please see \ref{section:PKIs}.
+
+In addition to the server providing its identity, a client might do so as well.
+That way mutual trust can be established. Another mechanism providing client
+authentication is Secure Remote Password (SRP)\todo{reference}. All those
+mechanisms require special configuration.
+
+Other authentication mechanisms like Pre Shared Keys aren't used in SSL/TLS.
+Anonymous sessions will not be discussed in this paper.
+
+\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 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
+
+\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:  
+%
+%\begin{itemize}
+%\item RFC2246 - TLS1.0                
+%\item RFC3268 - AES           
+%\item RFC4132 - Camelia               
+%\item RFC4162 - SEED          
+%\item RFC4279 - PSK           
+%\item RFC4346 - TLS 1.1               
+%\item RFC4492 - ECC           
+%\item RFC4785 - PSK\_NULL             
+%\item RFC5246 - TLS 1.2               
+%\item RFC5288 - AES\_GCM              
+%\item RFC5289 - AES\_GCM\_SHA2\_ECC           
+%\item RFC5430 - Suite B               
+%\item RFC5487 - GCM\_PSK              
+%\item RFC5489 - ECDHE\_PSK            
+%\item RFC5932 - Camelia               
+%\item RFC6101 - SSL 3.0               
+%\item RFC6209 - ARIA          
+%\item RFC6367 - Camelia               
+%\item RFC6655 - AES\_CCM              
+%\item RFC7027 - Brainpool Curves              
+%\end{itemize}
+
+%\subsubsection{Overview of SSL Server settings}
+%
+%
+%Most Server software (Webservers, Mail servers, etc.) can be configured to prefer certain cipher suites over others. 
+%We followed the recommendations by Ivan Ristic's SSL/TLS Deployment Best Practices\footnote{\url{https://www.ssllabs.com/projects/best-practices/index.html}} document (see section 2.2 "Use Secure Protocols") and arrived at a list of recommended cipher suites for SSL enabled servers.
+%
+%Following Ivan Ristic's adivce we arrived at a categorisation of cipher suites.
+%
+%\begin{center}
+%\begin{tabular}{lllll}
+%\cmidrule[\heavyrulewidth]{2-5}
+%& \textbf{Version}   & \textbf{KeyEx} & \textbf{Cipher}    & \textbf{MAC}       \\\cmidrule(lr){2-5}
+%\cellcolor{green}prefer  & TLS 1.2   & DHE\_DSS   & AES\_256\_GCM   & SHA384        \\
+%    &   & DHE\_RSA   & AES\_256\_CCM   & SHA256        \\
+%    &   & ECDHE\_ECDSA   & AES\_256\_CBC   &       \\
+%    &   & ECDHE\_RSA &   &       \\ 
+%    &   &   &   &       \\
+%\cellcolor{orange}consider    & TLS 1.1   & DH\_DSS    & AES\_128\_GCM   & SHA       \\
+%    & TLS 1.0   & DH\_RSA    & AES\_128\_CCM   &       \\
+%    &   & ECDH\_ECDSA    & AES\_128\_CBC   &       \\ 
+%    &   & ECDH\_RSA  & CAMELLIA\_256\_CBC  &       \\
+%    &   & RSA   & CAMELLIA\_128\_CBC  &       \\
+%    &   &   &   &       \\
+%\cellcolor{red}avoid   
+%& SSL 3.0   & NULL  & NULL  & NULL      \\
+%    &   & DH\_anon   & RC4\_128   & MD5       \\
+%    &   & ECDH\_anon & 3DES\_EDE\_CBC  &       \\
+%    &   &   & DES\_CBC   &       \\
+%    &   &   &   &       \\
+%\cellcolor{blue}{\color{white}special }
+%&   & PSK   & CAMELLIA\_256\_GCM  &       \\
+%    &   & DHE\_PSK   & CAMELLIA\_128\_GCM  &       \\
+%    &   & RSA\_PSK   & ARIA\_256\_GCM  &       \\
+%    &   & ECDHE\_PSK & ARIA\_256\_CBC  &       \\
+%    &   &   & ARIA\_128\_GCM  &       \\
+%    &   &   & ARIA\_128\_CBC  &       \\
+%    &   &   & SEED  &       \\
+%\cmidrule[\heavyrulewidth]{2-5}
+%\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.
+%
+%%% NOTE: s/forward secrecy/perfect forward secrecy???
+%
+%Note that the entries marked as ``special'' are cipher suites which are not common to all clients (webbrowsers etc).
+%
+%
+%\subsubsection{Tested clients}
+% 
+%Next we tested the cipher suites above on the following clients:
+%
+%%% NOTE: we need to test with more systems!!
+%\begin{itemize}
+%\item Chrome 30.0.1599.101 Mac OS X 10.9
+%\item Safari 7.0 Mac OS X 10.9
+%\item Firefox 25.0 Mac OS X 10.9
+%\item Internet Explorer 10 Windows 7
+%\item Apple iOS 7.0.3
+%\end{itemize}
+%
+%
+%The result of testing the cipher suites with these clients gives us a preference order as shown in table \ref{table:prefOrderCipherSuites}. 
+%Should a client not be able to use a specific cipher suite, it will fall back to the next possible entry as given by the ordering.
+%
+%\begin{table}[h]
+%\centering\small
+%    \begin{tabular}{cllcccc}
+%    \toprule
+%    \textbf{Pref}   & \textbf{Cipher Suite}                            & \textbf{ID}   & \multicolumn{4}{l}{\textbf{Supported by}}\\ 
+%    \cmidrule(lr){4-7}
+%                    & \textbf{OpenSSL Name}                            &               & Chrome & FF   & IE   & Safari \\
+%    \cmidrule(lr){1-7}
+%    \phantom{0}1    & \verb|TLS_DHE_RSA_WITH_AES_256_GCM_SHA384|     & \verb|0x009f| & \no    & \no  & \no  & \no    \\
+%                    & \verb|DHE-RSA-AES256-GCM-SHA384|                      &               & &&&\\\rowcolor{lightlightgray}
+%    \phantom{0}2    & \verb|TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384| & \verb|0xC024| & \no    & \no  & \no  & \yes   \\\rowcolor{lightlightgray}
+%                    & \verb|ECDHE-ECDSA-AES256-SHA384|                      &               & &&&\\
+%    \phantom{0}3    & \verb|TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384|   & \verb|0xC028| & \no    & \no  & \no  & \yes   \\
+%                    & \verb|ECDHE-RSA-AES256-SHA384|                        &               & &&&\\\rowcolor{lightlightgray}
+%    \phantom{0}4    & \verb|TLS_DHE_RSA_WITH_AES_256_CBC_SHA256|     & \verb|0x006B| & \yes   & \no  & \no  & \yes   \\\rowcolor{lightlightgray}
+%                    & \verb|DHE-RSA-AES256-SHA256|                          &               & &&&\\
+%    \phantom{0}5    & \verb|TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA|    & \verb|0xC00A| & \yes   & \yes & \yes & \yes   \\
+%                    & \verb|ECDHE-ECDSA-AES256-SHA|                         &               & &&&\\\rowcolor{lightlightgray}
+%    \phantom{0}6    & \verb|TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA|      & \verb|0xC014| & \yes   & \yes & \yes & \yes   \\\rowcolor{lightlightgray}
+%                    & \verb|ECDHE-RSA-AES256-SHA|                           &               & &&&\\
+%    \phantom{0}7    & \verb|TLS_DHE_RSA_WITH_AES_256_CBC_SHA|        & \verb|0x0039| & \yes   & \yes & \no  & \yes   \\
+%                    & \verb|DHE-RSA-AES256-SHA|                             &               & &&&\\\rowcolor{lightlightgray}
+%    \phantom{0}8    & \verb|TLS_DHE_DSS_WITH_AES_256_CBC_SHA|        & \verb|0x0038| & \no    & \yes & \yes & \no    \\\rowcolor{lightlightgray}
+%                    & \verb|DHE-DSS-AES256-SHA|                             &               & &&&\\
+%    \phantom{0}9    & \verb|TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA|   & \verb|0x0088| & \no    & \yes & \no  & \no    \\
+%                    & \verb|DHE-RSA-CAMELLIA256-SHA|                        &               & &&&\\\rowcolor{lightlightgray}
+%    \phantom{}10    & \verb|TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA|   & \verb|0x0087| & \no    & \yes & \no  & \no    \\\rowcolor{lightlightgray}
+%                    & \verb|DHE-DSS-CAMELLIA256-SHA|                        &               & &&&\\
+%   \bottomrule
+%    \end{tabular}
+%\caption{Preference order of cipher suites.  All suites are supported by OpenSSL.}
+%\label{table:prefOrderCipherSuites}
+%\end{table}
+%
+%Note: the above table \ref{table:prefOrderCipherSuites} contains Elliptic curve key exchanges. There are currently strong doubts\footnote{\url{http://safecurves.cr.yp.to/rigid.html}} concerning ECC.
+%If unsure, remove the cipher suites starting with ECDHE in the table above.
+%
+%
+%Based on this ordering, we can now define the corresponding settings for servers. We will start with the most common web servers.
diff --git a/src/theory/cipher_suites/compatibility.tex b/src/theory/cipher_suites/compatibility.tex
new file mode 100644 (file)
index 0000000..d8621fd
--- /dev/null
@@ -0,0 +1,2 @@
+%%\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.}
\ No newline at end of file
diff --git a/src/theory/cipher_suites/forward.tex b/src/theory/cipher_suites/forward.tex
new file mode 100644 (file)
index 0000000..e7a9ab6
--- /dev/null
@@ -0,0 +1,8 @@
+%%\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 adversary
+has got hold of the server key
+\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}}
+\footnote{\url{http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html}}.
diff --git a/src/theory/cipher_suites/insecure.tex b/src/theory/cipher_suites/insecure.tex
new file mode 100644 (file)
index 0000000..585af09
--- /dev/null
@@ -0,0 +1,17 @@
+%%\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!}
+
+%%Ciphers with 112bit or less are considered weak and aren't recommended. Note that \texttt{3DES} provides only 112bit of security \footnote{\url{http://csrc.nist.gov/publications/PubsSPs.html\#800-57-part1}}.
+
+%% comment Florian:
+%% Please do not consider ciphers with a 112 bit key as weak. I think it is
+%% fine to do not recommend 3DES, but we should not claim that it is weak.
+%% In particular, 3DES with an effective keysize of 112 bits is still
+%% recommended by NIST and by ECRYPT2 for medium-term protection until 2030.
+
+
+%One special remark is necessary for 3DES: here we want to note
+%that it theoretically has 168 bit security, however based on the NIST Special
+%Publication 800-57
+%\footnote{\url{http://csrc.nist.gov/publications/PubsSPs.html\#800-57-part1},
+%pages 63 and 64}, it is clear that 3DES is only considered 80 bits / 112 bits.
diff --git a/src/theory/cipher_suites/recommended.tex b/src/theory/cipher_suites/recommended.tex
new file mode 100644 (file)
index 0000000..dd84b85
--- /dev/null
@@ -0,0 +1,166 @@
+%%\subsection{Recommended cipher suites}
+
+In principle system administrators who want to improve their communication security
+have to make a difficult decision between effectively locking out some users and 
+keeping high cipher suite security while supporting as many users as possible.
+The website \url{https://www.ssllabs.com/} gives administrators and security engineers
+a tool to test their setup and compare compatibility with clients. The authors made 
+use of ssllabs.com to arrive at a set of cipher suites which we will recommend 
+throughout this document.\\
+
+\textbf{Caution: these settings can only represent a subjective
+choice of the authors at the time of writing. It might be a wise choice to
+select your own and review cipher suites based on the instructions in section
+\ref{section:ChoosingYourOwnCipherSuites}}.
+
+
+\subsubsection{Configuration A: Strong ciphers, fewer clients}
+
+At the time of writing we recommend the following set of strong cipher
+suites which may be useful in an environment where one does not depend on many,
+different clients and where compatibility is not a big issue.  An example
+of such an environment might be machine-to-machine communication or corporate
+deployments where software that is to be used can be defined freely.
+
+
+We arrived at this set of cipher suites by selecting:
+
+\begin{itemize}
+\item TLS 1.2
+\item Perfect forward secrecy / ephemeral Diffie Hellman
+\item strong MACs (SHA-2) or
+\item GCM as Authenticated Encryption scheme
+\end{itemize}
+
+This results in the OpenSSL string:
+
+\begin{lstlisting}[breaklines]
+'EDH+aRSA+AES256:EECDH+aRSA+AES256:!SSLv3'
+\end{lstlisting}
+
+%$\implies$ resolves to 
+%
+%\begin{verbatim}
+%openssl ciphers -V $string
+%\end{verbatim}
+
+
+
+%\todo{make a column for cipher chaining mode} --> not really important, is it?
+\begin{center}
+
+\begin{tabular}{lllllll}
+\toprule
+\textbf{ID}   & \textbf{OpenSSL Name}       & \textbf{Version} & \textbf{KeyEx} & \textbf{Auth} & \textbf{Cipher} & \textbf{MAC}\\\cmidrule(lr){1-7}
+\verb|0x009F| & DHE-RSA-AES256-GCM-SHA384   & TLSv1.2          & DH             &  RSA          & AESGCM(256)     & AEAD         \\
+\verb|0x006B| & DHE-RSA-AES256-SHA256       & TLSv1.2          & DH             &  RSA          & AES(256) (CBC)  & SHA256       \\
+\verb|0xC030| & ECDHE-RSA-AES256-GCM-SHA384 & TLSv1.2          & ECDH           &  RSA          & AESGCM(256)     & AEAD         \\
+\verb|0xC028| & ECDHE-RSA-AES256-SHA384     & TLSv1.2          & ECDH           &  RSA          & AES(256) (CBC)  & SHA384       \\
+\bottomrule
+\end{tabular}
+\end{center}
+
+
+\textbf{Compatibility}
+
+Only clients which support TLS 1.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).
+
+
+
+\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.  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}.\\
+
+We arrived at this set of cipher suites by selecting:
+
+\begin{itemize}
+\item TLS 1.2, TLS 1.1, TLS 1.0
+\item allow 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 OpenSSL string:
+
+\begin{lstlisting}[breaklines]
+'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA'
+\end{lstlisting}
+
+\todo{make a column for cipher chaining mode}
+\begin{center}
+\begin{tabular}{lllllll}
+\toprule
+\textbf{ID}   & \textbf{OpenSSL Name}       & \textbf{Version} & \textbf{KeyEx} & \textbf{Auth} & \textbf{Cipher} & \textbf{MAC}\\\cmidrule(lr){1-7}
+\verb|0x009F| & DHE-RSA-AES256-GCM-SHA384   & TLSv1.2          & DH             & RSA           & AESGCM(256)     & AEAD         \\
+\verb|0x006B| & DHE-RSA-AES256-SHA256       & TLSv1.2          & DH             & RSA           & AES(256)        & SHA256       \\
+\verb|0xC030| & ECDHE-RSA-AES256-GCM-SHA384 & TLSv1.2          & ECDH           & RSA           & AESGCM(256)     & AEAD         \\
+\verb|0xC028| & ECDHE-RSA-AES256-SHA384     & TLSv1.2          & ECDH           & RSA           & AES(256)        & SHA384       \\
+\verb|0x009E| & DHE-RSA-AES128-GCM-SHA256   & TLSv1.2          & DH             & RSA           & AESGCM(128)     & AEAD         \\
+\verb|0x0067| & DHE-RSA-AES128-SHA256       & TLSv1.2          & DH             & RSA           & AES(128)        & SHA256       \\
+\verb|0xC02F| & ECDHE-RSA-AES128-GCM-SHA256 & TLSv1.2          & ECDH           & RSA           & AESGCM(128)     & AEAD         \\
+\verb|0xC027| & ECDHE-RSA-AES128-SHA256     & TLSv1.2          & ECDH           & RSA           & AES(128)        & SHA256       \\
+\verb|0x0088| & DHE-RSA-CAMELLIA256-SHA     & SSLv3            & DH             & RSA           & Camellia(256)   & SHA1         \\
+\verb|0x0039| & DHE-RSA-AES256-SHA          & SSLv3            & DH             & RSA           & AES(256)        & SHA1         \\
+\verb|0xC014| & ECDHE-RSA-AES256-SHA        & SSLv3            & ECDH           & RSA           & AES(256)        & SHA1         \\
+\verb|0x0045| & DHE-RSA-CAMELLIA128-SHA     & SSLv3            & DH             & RSA           & Camellia(128)   & SHA1         \\
+\verb|0x0033| & DHE-RSA-AES128-SHA          & SSLv3            & DH             & RSA           & AES(128)        & SHA1         \\
+\verb|0xC013| & ECDHE-RSA-AES128-SHA        & SSLv3            & ECDH           & RSA           & AES(128)        & SHA1         \\
+\verb|0x0084| & CAMELLIA256-SHA             & SSLv3            & RSA            & RSA           & Camellia(256)   & SHA1         \\
+\verb|0x0035| & AES256-SHA                  & SSLv3            & RSA            & RSA           & AES(256)        & SHA1         \\
+\verb|0x0041| & CAMELLIA128-SHA             & SSLv3            & RSA            & RSA           & Camellia(128)   & SHA1         \\
+\verb|0x002F| & AES128-SHA                  & SSLv3            & RSA            & RSA           & AES(128)        & SHA1         \\
+\bottomrule
+\end{tabular}
+\end{center}
+
+\textbf{Compatibility}
+
+Note that these cipher suites will not work with Windows XP's crypto stack (e.g. 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) \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). 
+\todo{do that!}
+
+\textbf{Explanation}
+
+For a detailed explanation of the cipher suites chosen, please see
+\ref{section:ChoosingYourOwnCipherSuites}. In short, finding the perfect cipher
+string is impossible and must be a tradeoff between compatibility and security. 
+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.
+
+Straight forward, the authors wanted strong ciphers, forward secrecy
+\footnote{\url{http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forward.html}}
+and the best client compatibility possible while still ensuring a cipher string that can be
+used on legacy installations (e.g. OpenSSL 0.9.8). 
+
+Our recommended cipher strings are meant to be used via copy and paste and need to work
+"out of the box".
+
+\begin{itemize}
+\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.
+\item AES128 and CAMELLIA128 count as strong ciphers at the moment
+\item DHE or ECDHE for forward secrecy
+\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
+      legacy distributions of OpenSSL will work out of the box. Forward secrecy
+      will not be available. On systems that do not support elliptic curves, that cipher
+      offers support for the Microsoft crypto libraries that only support ECDHE. \todo{what does that mean?! inconclusive!}
+\end{itemize}
+
+\todo{Adi: review "justification" when next section is written}