more reviewer input, mostly wording

diff --git a/src/acknowledgements.tex b/src/acknowledgements.tex
index 686ac62..339bd68 100644 (file)
--- a/src/acknowledgements.tex
+++ b/src/acknowledgements.tex
@@ -32,6 +32,7 @@ San, Berg \\
 Schreck, Thomas  \\
 Seidl, Eva (PDF layout) \\
 Wagner, Sebastian (``sebix'') \\
+Zangerl, Alexander \\
 \end{minipage}
 
 \vline{}

diff --git a/src/ssllibs.tex b/src/ssllibs.tex
index bee8583..09ec9d1 100644 (file)
--- a/src/ssllibs.tex
+++ b/src/ssllibs.tex
@@ -10,7 +10,7 @@ using that feature. An example for that may be Apache supporting elliptic curve
 cryptography only from version 2.4 onwards, no matter if OpenSSL supported it or
 not.
 
-As you may see from the above, creating a secure setup isn't just a matter of
+As explained above, creating a secure setup isn't just a matter of
 configuration but also depends on several other factors with the most important
 being the SSL libraries and their support of protocols and cipher suites.
 Furthermore, applications actually need to make use of those.
@@ -23,9 +23,10 @@ string however is common to all versions and and library implementations:
 \texttt{TLS\_RSA\_CAMELLIA\_256\_CBC\_SHA1} in GnuTLS is equivalent to
 \texttt{CAMELLIA256-SHA} in OpenSSL and \texttt{TLS\_RSA\_WITH\_CAMELLIA\_256\_CBC\_SHA}
 in the IANA standard with the hex code \texttt{0x00,0x84} as specified
-in RFC5932\cite{rfc5932}.
+in RFC5932\cite{rfc5932}. Section \ref{section:cipher_suite_names}
+lists all currently defined cipher suites with their codes and both names.
 
-In any way, as a sysadmin you are required to check what the SSL libraries on
+Regardless of this clash of nomenclature, as a sysadmin you are required to check what the SSL libraries on
 your systems support on how you may get the most security out of your systems.
 
 \subsection{priority strings}

diff --git a/src/theory/cipher_suites/recommended.tex b/src/theory/cipher_suites/recommended.tex
index 0a7e66c..11c0ced 100644 (file)
--- a/src/theory/cipher_suites/recommended.tex
+++ b/src/theory/cipher_suites/recommended.tex
@@ -16,11 +16,11 @@ throughout this document.\\
 
 \subsubsection{Configuration A: Strong ciphers, fewer clients}
 
-At the time of writing we recommend the following set of strong cipher
+At the time of writing, our recommendation is to use 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.
+deployments where software that is to be used can be defined without restrictions.
 
 
 We arrived at this set of cipher suites by selecting:
@@ -69,12 +69,12 @@ Win 7 and Win 8.1 crypto stack, Opera 17, OpenSSL $\ge$ 1.0.1e, Safari 6 / iOS
 
 
 
-\subsubsection{Configuration B: Weaker ciphers, more compatibility}
+\subsubsection{Configuration B: Weaker ciphers but better compatibility}
 
 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
+example, there are 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
+better compatibility with a broad range of clients, but also less computational
 workload on the provisioning hardware.
 \\
 
@@ -135,8 +135,8 @@ DH-parameter length limitation (1024 bit).
 \paragraph*{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. 
+\ref{section:ChoosingYourOwnCipherSuites}. In short, finding a single perfect cipher
+string is practically impossible and there 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.