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

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 10 July 2018 04:17 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4697A130EF6 for <tls@ietfa.amsl.com>; Mon, 9 Jul 2018 21:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_iK6E-9LG6P for <tls@ietfa.amsl.com>; Mon, 9 Jul 2018 21:17:57 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13629130DC6 for <tls@ietf.org>; Mon, 9 Jul 2018 21:17:56 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 23CCB29AF43; Tue, 10 Jul 2018 00:17:56 -0400 (EDT)
Date: Tue, 10 Jul 2018 00:17:56 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20180710041755.GD85096@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <CAHbuEH5J-F2cKag02Vx416jsy1N6XZOju28H99WAt71Pc5optg@mail.gmail.com> <CABkgnnUhC5O-XuPnxzgt-_T4pzw0MiwP3GYXYp45xFso8R2osA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABkgnnUhC5O-XuPnxzgt-_T4pzw0MiwP3GYXYp45xFso8R2osA@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/gWNMDDGeUurNAMnE5zcfmjsTjLw>
Subject: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jul 2018 04:17:59 -0000

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.