[TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt)

[Viktor Dukhovni <[e-mail]>]

On Tue, Jul 10, 2018 at 08:56:14AM +1000, Martin Thomson wrote:

> Is there any reason why we wouldn't also consider deprecating cipher
> suites we don't like?  For instance, RFC 5246 mandates the
> implementation of TLS_RSA_WITH_AES_128_CBC_SHA, which we can probably
> agree isn't ideal for several reasons.

Is the objection primarily to AES-128-CBC or to RSA key exchange?
With EtM there's AFAIK/IMHO not much wrong with AES-128-CBC, it
outperforms AES-256-CBC, and the various CBC issues are resolved
via EtM.

> The ECDHE suites with AES-GCM
> are widely available, perhaps widely enough that we might consider a
> stronger move and update 5246 to modern suites.

More generally, as noted in RFC7435, you get more security by raising
the ceiling than by raising the floor.  Breaking the ability to
communicate with legacy systems may feel satisfying, but does not
generally improve the security of the up-to-date systems, barring
downgrade issues in the protocol.

Therefore, we should focus on remediating any downgrade exposures,
those are serious issues regardless of the mix of supported algorithms,
and with downgrade under control, and up-to-date systems preferring
stronger algorithms, removal of obsolete algorithms becomes
considerably less urgent.  They can fade out of use gradually with
minimal disruption.

Setting the bar too high creates barriers to adoption of security
mechanisms.   Detailed example below, TL;DR turning off trust in
SHA-1 certificates is not always a good idea.

For example, I recently learned that current GnuTLS
versions by default no longer validate certificates with SHA-1
issuer signatures, and that current versions of Exim linked with
these GnuTLS releases fail to validate some DANE-TA(2) chains issued
by private-CAs that still use SHA-1.  And yet:

   * CA/B forum public CAs in the various browser bundles no
     longer issue SHA-1 certificates.

	https://cabforum.org/2014/10/16/ballot-118-sha-1-sunset/

   * Furthermore, they now also employ high-entropy unpredictabl
     serial numbers:

        https://cabforum.org/2016/03/31/ballot-164/

Thus there is no practical exposure to SHA-1 via the public CA
ecosystem, and as the issue is comprehensively addressed on the
issuer side.


Non-public CAs, on the other hand, are typically already compromised
by the time they can be convinced to issue certificates to untrusted
strangers, even if the hash algorithm is impeccably strong.  If an
organization designates its own private CA (that still issues SHA-1
signed certificates) as the trust-anchor for its SMTP servers, it
is counter-productive for the verifier[*] to demand greater security
connections to that site than the site deems necessary.

Thus, ideally, either general purpose TLS libraries (such as GnuTLS)
should not yet disable verification of SHA-1 certs in their chain
verification code, or else, Exim and other applications need to
explicitly override the default settings and re-enable SHA-1.

Yes, in practice, given that getting the world to change their
deployed systems is hard, also the private CAs using SHA-1 will
need to switch to SHA-2 to regain interoperability, despite no
actual risk from SHA-1.

For the record, SHA-1 use is not common.  From the SMTP DANE adoption
survey, looking at the 537 distinct leaf certificates of the 655
MX hosts with DANE-TA(2) (issuer-CA rather than the much more popular
DANE-EE(3) leaf cert) TLSA records I observe the below signature
algorithm frequency:

 496     Signature Algorithm: sha256WithRSAEncryption
  27     Signature Algorithm: sha512WithRSAEncryption
   8     Signature Algorithm: sha1WithRSAEncryption
   4     Signature Algorithm: ecdsa-with-SHA256
   2     Signature Algorithm: sha384WithRSAEncryption

So Exim with recent GnuTLS fails to authenticate 8 MX hosts, serving
around 30 domains, due to deprecation of SHA-1 in a context where
it is largely unnecessary and is somewhat counter-productive.

-- 
	Viktor.

[*] The verifier is almost always employing opportunistic DANE TLS,
    and is even willing to send cleartext when DNSSEC-secure DANE
    TLSA records are absent and STARTTLS is absent or stripped.
    Thus the use of mandatory TLS is at the receiving domains's
    prerogative.  Holding the receiing system to a higher security
    bar than it provisioned is counter-productive.