Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 02 January 2014 22:50 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: therightkey@ietfa.amsl.com
Delivered-To: therightkey@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8296F1ACC88 for <therightkey@ietfa.amsl.com>; Thu, 2 Jan 2014 14:50:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 gzHl5xHwvsEM for <therightkey@ietfa.amsl.com>; Thu, 2 Jan 2014 14:50:48 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5F01A8026 for <therightkey@ietf.org>; Thu, 2 Jan 2014 14:50:48 -0800 (PST)
Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s02MocKi014717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Jan 2014 15:50:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host sn80.proper.com [75.101.18.80] claimed to be [165.227.249.247]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <52C5B67D.4050301@appelbaum.net>
Date: Thu, 2 Jan 2014 14:50:42 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <A8E9A208-35FA-495F-8130-C08545011B59@vpnc.org>
References: <22429D73-4EFC-4091-8F5B-BAD38968EA54@taoeffect.com> <CAMm+LwiMXdEnHqD0y_S-fP6081Tk=A=7-9LsJQhRuawmmmfdTg@mail.gmail.com> <FEFA307D-97E0-4C58-AB43-5B9AB8E8FC70@taoeffect.com> <CAMm+Lwjwww28tV_qvqQVH3xo1xqvjb6z++258+LOqgxWn-Oh9w@mail.gmail.com> <52B88104.9040607@appelbaum.net> <52C2D54F.8000209@comodo.com> <52C45CDC.5020608@appelbaum.net> <96EF8E55-5860-4534-B370-83395C3985D4@vpnc.org> <52C5B67D.4050301@appelbaum.net>
To: Jacob Appelbaum <jacob@appelbaum.net>
X-Mailer: Apple Mail (2.1827)
Cc: therightkey@ietf.org
Subject: Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security
X-BeenThere: therightkey@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <therightkey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/therightkey>, <mailto:therightkey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/therightkey/>
List-Post: <mailto:therightkey@ietf.org>
List-Help: <mailto:therightkey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/therightkey>, <mailto:therightkey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jan 2014 22:50:49 -0000

On Jan 2, 2014, at 10:57 AM, Jacob Appelbaum <jacob@appelbaum.net> wrote:

> I control the private key for the rouge CA that we created.

True. However, that rogue CA is not trusted in any root pile, right? You holding a private key for a trusted CA was, appropriately a big deal. You holding a private key for an untrusted CA is uninteresting.


>> As you certainly know, that attack only
>> applied to a very limited number of CAs in the root piles at the
>> time.
> 
> I'm not sure where you came to this impression?

By counting the number of CAs who used MD5 and had predictable serial numbers.

> There were a few CAs who
> were vulnerable, we picked one to perform the research. It worked. That
> work produced a valid signature that we could apply to our second
> certificate, which is a sub-CA certificate. Thus, the attack we did only
> applied to a single CA and we did not destroy the private key for the
> corresponding certificate. So yes, we most certainly do have the private
> key for that intermediate certificate authority that we created.

All true, but no longer relevant.

>> I I remember correctly, it applied to zero of them
>> approximately six months later.
> 
> Unless one explicitly distrusts (all) MD5 signed certificates, pre-loads
> our certificate to mark it as untrusted, or a few other things relating
> to time constraints - it will probably still work for MITM attacks.

It sounds like you are saying that the contents of the issued certificates don't need to be predictable for the collision to happen. That would be absurd. Again, please don't overstate the value of your demonstration. It was a very good thing because it got people to look and *and fix* the problem. Can you point to a single CA in any of the common trust stores that both use MD5 and issue certificates with less than 2^64 bits of unpredictability?

> Many
> applications fail to do proper constraint checking.

Which is just fine. It should be up to the people putting together the trust pile to do the checking, not the relying parties.

> I'm not overstating anything.

We disagree.

> I think you don't understand what we
> actually did if you think that later, patching things will somehow
> magically stop previously successful attacks...

Ummm, where did I say anything about "patching"? I said that I believed that there were no more CAs who were vulnerable, and asked you to show where you thought there was. If you're right, then that's very valuable information. I don't see any more in the trust piles that I look through, but I could be missing something.

--Paul Hoffman