Re: [TLS] Certificate keyUsage enforcement [whose duty, client's or server's?]

Peter Gutmann <pgut001@cs.auckland.ac.nz> Thu, 08 November 2018 02:20 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 60C1D130DE9 for <tls@ietfa.amsl.com>; Wed, 7 Nov 2018 18:20:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 vXHyEWsKVGhU for <tls@ietfa.amsl.com>; Wed, 7 Nov 2018 18:20:03 -0800 (PST)
Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47751130DFD for <tls@ietf.org>; Wed, 7 Nov 2018 18:20:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1541643602; x=1573179602; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=yI2SPV+2bzT/mFhYiLWrXHeOdAwLWR4g5O21apppjBw=; b=1Yhe8+z11KXReVWDXZdPZ0cEKOx5aq7qWlYqdBR5NhCycOC0p0I8InL7 jDLR0M12pfMCnwUSKMXrfeJF80Cgjbl1qrPKVbQAdonYx6acNg4LmWhDO RaBBq6kvme/hcpJD40S5eVhQMOxmVUS9N+EjgB0XgM19GCkdj4cKWeA0B tQGTWDlqeYr6O97EJS/umimJFeSjYUSnDnoLczGR2HivD5AXa0zZO0LUZ OA5d0R2K0Phulg146OKVUWT8YLhhiQn6d3Ai/zji7OGusVmwxI0U1fJDp NA0NNvED9iMrlgmuoD4hJfKHw2YJ7+VvLTkXy1+sT9DEi9jL14ec0E3wj g==;
X-IronPort-AV: E=Sophos;i="5.54,478,1534766400"; d="scan'208";a="38712086"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing
Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-ogg-a.UoA.auckland.ac.nz) ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Nov 2018 15:19:56 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.2) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 8 Nov 2018 15:19:56 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Thu, 8 Nov 2018 15:19:56 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Certificate keyUsage enforcement [whose duty, client's or server's?]
Thread-Index: AQHUdrDkd3KhNEmzUka2XQqjxPCtTKVFJQ2I
Date: Thu, 08 Nov 2018 02:19:56 +0000
Message-ID: <1541643589219.59850@cs.auckland.ac.nz>
References: <79CF87E7-E263-4457-865E-F7BE8251C506@dukhovni.org> <m236seg80v.fsf@localhost.localdomain> <20181107144826.207DC404C@ld9781.wdf.sap.corp>, <20181107154452.GN4122@straasha.imrryr.org>
In-Reply-To: <20181107154452.GN4122@straasha.imrryr.org>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Z3Ep6ef2wqBXEkzlOsMKdkIHkhM>
Subject: Re: [TLS] Certificate keyUsage enforcement [whose duty, client's or server's?]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 08 Nov 2018 02:20:05 -0000

Viktor Dukhovni <ietf-dane@dukhovni.org> writes:

>On Wed, Nov 07, 2018 at 03:48:26PM +0100, Martin Rex wrote:
>> There is *ZERO* security problem associated with TLS client allowing
>> a TLS server to do this, but it makes it harder to catch defective
>> CA software and bogus CA issuing practices when clients do not complain
>> here
>
>The interoperability issues I'm seeing are with self-signed certificates used
>in opportunistic TLS and DANE in SMTP.  The CA is some end-user, who "does not
>know any better", and the question is how pedantic should the client's TLS
>stack be in such a case.

My code, by default, strictly enforces keyUsage [0], so I end up seeing all
the broken certs out there, and it's complete chaos, (DH) keyAgreement set for
RSA certs, every possible key usage (includings ones the algorithm isn't
capable of) set, things like email encryption and SSL server set for CA certs
(extKeyUsage), keyEncipherment for signing keys, digitalSignature for
encryption keys, it's the Rule 34 of PKI (if you can think of it, someone's
put it in an extension).  This includes CA-issued certs, not self-signed ones.
I think a significant chunk of TLS PKI only works because implementations
don't strictly enforce keyUsage.

Peter.

[0] Which probably wasn't the best default setting.  If you think the public
    web PKI has broken certs, you should see what turns up in the SCADA 
    world...