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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Thu, 08 November 2018 02:59 UTC

Return-Path: <prvs=48507c1ba2=uri@ll.mit.edu>
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 5CB1F127598 for <tls@ietfa.amsl.com>; Wed, 7 Nov 2018 18:59:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=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 YPR-lofb3W9G for <tls@ietfa.amsl.com>; Wed, 7 Nov 2018 18:59:02 -0800 (PST)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id C99AD130E23 for <tls@ietf.org>; Wed, 7 Nov 2018 18:59:01 -0800 (PST)
Received: from LLE2K16-MBX03.mitll.ad.local (LLE2K16-MBX03.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id wA82wu7X024611; Wed, 7 Nov 2018 21:58:56 -0500
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Certificate keyUsage enforcement [whose duty, client's or server's?]
Thread-Index: AQHUdrD9Oe3OsrSfp0iLUI3S9OSzX6VFeYQAgAAK4wA=
Date: Thu, 08 Nov 2018 02:58:55 +0000
Message-ID: <759EDF0B-2D80-4D31-B3AE-7B04F443B4E8@ll.mit.edu>
References: <79CF87E7-E263-4457-865E-F7BE8251C506@dukhovni.org> <m236seg80v.fsf@localhost.localdomain> <20181107144826.207DC404C@ld9781.wdf.sap.corp> <20181107154452.GN4122@straasha.imrryr.org> <1541643589219.59850@cs.auckland.ac.nz>
In-Reply-To: <1541643589219.59850@cs.auckland.ac.nz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
Content-Type: multipart/signed; boundary="Apple-Mail-779934AB-8743-48E1-8BF7-FD3DCBFF35A2"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-08_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811080022
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WpJJ0VL1KGX5ce-CGgag6OE7B58>
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:59:04 -0000

Peter, 

I think your code did exactly right. The standard requires honoring KeyUsage.

Maybe if more implementations were diligent with this, the cert zoo we're observing would've been less wild...

Regards,
Uri

Sent from my iPhone

> On Nov 7, 2018, at 21:21, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
> 
> 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...
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls