Re: [TLS] Certificate validation can of worms

Phillip Hallam-Baker <hallam@gmail.com> Wed, 09 April 2014 00:41 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C40A1A06F6 for <tls@ietfa.amsl.com>; Tue, 8 Apr 2014 17:41:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 p1M_x3ehciny for <tls@ietfa.amsl.com>; Tue, 8 Apr 2014 17:41:08 -0700 (PDT)
Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 48E691A0192 for <tls@ietf.org>; Tue, 8 Apr 2014 17:41:07 -0700 (PDT)
Received: by mail-bk0-f49.google.com with SMTP id my13so1609424bkb.36 for <tls@ietf.org>; Tue, 08 Apr 2014 17:41:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vccs9ueOPOrASzUaXGnWh97dyLopaYtYJzGrXn7uVIU=; b=mLwbU9x64cTwD9DsE2b5VnGNfEateXsQcOV/AK9AkIscKv2mMG608r1rPxvbkCSsI8 SN8WZK6d71jNJgCgbguATD9XSiuK59Uy3i4PJGbjp255qHptOQneVPIAfcEDsiEnj1sD ISm5nZl+QyGpqzxWWKayeIukV/T3pDtoh5t51qWU9eAXQblPdMErggjfiNT8Aod/Dubp Nfl99GlDFoOKSpGlKODLJDThWKyJpWNLFf+4EOao8p43os5Uy3HAuw3sqFauo1vDRlWL tjrZIlL8Wc/TT9UAG8LqSCv6f2iD0h+YvjuNTofT5v5aoRfZFH0/iBnPEFXV9SzL1+WA RumA==
MIME-Version: 1.0
X-Received: by 10.152.87.71 with SMTP id v7mr5079747laz.10.1397004067329; Tue, 08 Apr 2014 17:41:07 -0700 (PDT)
Received: by 10.112.234.229 with HTTP; Tue, 8 Apr 2014 17:41:07 -0700 (PDT)
In-Reply-To: <CACsn0ck8OP+qThaVVVBF29FQ6krZUvC12B4ymHx61+qxMzAZNQ@mail.gmail.com>
References: <534320A2.5030208@comodo.com> <20140407224329.4A71F1ACAA@ld9781.wdf.sap.corp> <CACsn0ckKEMTWMH=0+=Bbp8djnKtbawkcVeEujnonBB_8ND03_Q@mail.gmail.com> <1396944418.11019.10.camel@dhcp-2-127.brq.redhat.com> <CAMm+Lwjqv0nib0JRXO87ZckjiDhzkhJM2JwmBs=5P3hQchkg1w@mail.gmail.com> <CACsn0ck8OP+qThaVVVBF29FQ6krZUvC12B4ymHx61+qxMzAZNQ@mail.gmail.com>
Date: Tue, 08 Apr 2014 20:41:07 -0400
Message-ID: <CAMm+Lwi-mxguOrcD3ndFKeVv36pGCC7JfWJAAs6hbwfpH5rFzQ@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZJgoAodJYFy9jh1Woqqy9i3P1Pw
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Certificate validation can of worms
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 09 Apr 2014 00:41:12 -0000

On Tue, Apr 8, 2014 at 12:05 PM, Watson Ladd <watsonbladd@gmail.com> wrote:

>> The requirement to mark the certificate critical enabled the NSA
>> attack on Microsoft in the Flame malware attack. Marking the bit
>> critical makes it impossible to issue a certificate with that
>> extension as about half a billion deployed devices don't support name
>> constraints.
>
> ?? Flame was a MD5 collision. Nothing saves you from that one.

Had name constraints been deployable and deployed, the Microsoft CA
that the NSA attacked could have been locked down to mitigate the
consequences of a breach.


>> The consensus model does not really work when a specification has been
>> poisoned by an attacker who can block changes to correct the spec.
>> Fortunately IETF specifications are not definitive, industry practice
>> is. The industry consensus on this point is unanimous: name
>> constraints need not be marked critical.
>
> Which makes them useless: the point of name constraints is that I can
> issue a name constrained certificate without issuing a global
> intermediate CA certificate. If the extension is not marked critical,
> then I've issued a global intermediate CA certificate for those who
> don't check it, and so need to be just as strict as if it was an
> intermediate CA certificate, so I might as well not bother with the
> constraint.

Again, you don't get the idea that redundant controls have value. Even
though I have full control over the signing key for a sub-ca, there is
no reason for the sub-ca to have the power to issue any cert so why
grant it?

Least privilege is a powerful tool. The IETF had no business telling
people they couldn't use it.

You have no idea what my requirements or constraints are. So why
presume to tell us what is or is not useful?

The IETF was following an outdated mode of security thinking. One that
is unfortunately very common in US government contractor circles.


A MUST is only justified when there is a serious negative consequence
from not following it. There is no serious consequence that follows
from not marking a name constraint critical in the context in which it
is now used in the industry.

The clear industry consensus is that name constraints MAY be marked as
non-critical.

-- 
Website: http://hallambaker.com/