Document problems with SHA-1 in certs with DANE-TA

Very few domains are using SHA-1 in EE certs issued from a CA used in
DANE-TA anchoring, but some are.  Meanwhile apparently GnuTLS now
defaults to disabling SHA-1 in chains.  Which is eminently reasonable.

I do not believe that Exim should re-enable use of SHA-1 here.  Let it
die.  Document with warnings that folks using a private CA for certs to
be publicly trusted via DANE-TA should follow decent operational
issuance practices.

Also update my Channel Binding docs for GSASL to warn that Channel
Binding is Broken™.

1 files changed, 7 insertions, 3 deletions

diff --git a/doc/doc-txt/GnuTLS-FAQ.txt b/doc/doc-txt/GnuTLS-FAQ.txt
index 897087582..ab4e5aaa6 100644
--- a/doc/doc-txt/GnuTLS-FAQ.txt
+++ b/doc/doc-txt/GnuTLS-FAQ.txt
@@ -6,7 +6,7 @@ Using Exim 4.80+ with GnuTLS
 (3) I'm seeing:
     "(gnutls_handshake): A TLS packet with unexpected length was received"
     Why?
-(4) What's the deal with MD5?
+(4) What's the deal with MD5?  (And SHA-1?)
 (5) What happened to gnutls_require_kx / gnutls_require_mac /
     gnutls_require_protocols?
 (6) What's the deal with tls_dh_max_bits?  What's DH?
@@ -89,8 +89,8 @@ option fixes the problem, this was the cause.  See Q6.
 
 
 
-(4): What's the deal with MD5?
-------------------------------
+(4): What's the deal with MD5?  (And SHA-1?)
+--------------------------------------------
 
 MD5 is a hash algorithm.  Hash algorithms are used to reduce a lot of data
 down to a fairly short value, which is supposed to be extremely hard to
@@ -119,6 +119,10 @@ the ongoing costs of proving a trust relationship, such as providing
 revocation protocols.  This is just another of those ongoing costs you have
 already paid for.
 
+The same has happened to SHA-1: there are real-world collision attacks against
+SHA-1, so SHA-1 is mostly defunct in certificates.  GnuTLS no longer supports
+its use in TLS certificates.
+
 
 
 (5): ... gnutls_require_kx / gnutls_require_mac / gnutls_require_protocols?