Re: [TLS] Collisions (Re: Consensus Call: FNV vs SHA1)

Marsh Ray <marsh@extendedsubset.com> Wed, 12 May 2010 03:29 UTC

Return-Path: <marsh@extendedsubset.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1650F28C0EC for <tls@core3.amsl.com>; Tue, 11 May 2010 20:29:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.71
X-Spam-Level:
X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[AWL=0.889, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+QhrNPG356g for <tls@core3.amsl.com>; Tue, 11 May 2010 20:29:19 -0700 (PDT)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 4300128C0E3 for <tls@ietf.org>; Tue, 11 May 2010 20:29:19 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1OC2dA-000NEQ-FD; Wed, 12 May 2010 03:29:08 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 8F0C0631D; Wed, 12 May 2010 03:29:05 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1+rT5q/f2VKJjFQF8++DWZfEK0XvvWPia0=
Message-ID: <4BEA2083.5000509@extendedsubset.com>
Date: Tue, 11 May 2010 22:29:07 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: Stefan Santesson <stefan@aaa-sec.com>
References: <C80F9353.ABE0%stefan@aaa-sec.com>
In-Reply-To: <C80F9353.ABE0%stefan@aaa-sec.com>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Simon Josefsson <simon@josefsson.org>, tls@ietf.org
Subject: Re: [TLS] Collisions (Re: Consensus Call: FNV vs SHA1)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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, 12 May 2010 03:29:20 -0000

On 5/11/2010 4:05 PM, Stefan Santesson wrote:
> On 10-05-12 12:55 AM, "Marsh Ray" <marsh@extendedsubset.com> wrote:
> 
>>
>>> On the other hand, I would not object to include a requirement that data
>>> should/must only be cached from a successful handshake where the server is
>>> successfully authenticated. That should remove any residue of this issue.
>>
>> If "successfully authenticated" is only fully determined sometime after
>> returning application code, does that mean that this extension should
>> never come enabled by default for a TLS library?
> 
> There is a difference between passing path validation, which is done by the
> crypto library, and deciding if the certificate subject is an appropriate
> entity, which is done by the application.
> 
> In this case I think it is enough that the certificate pass path validation
> to a trusted root.

Usually something like that is either critical to the security of the
protocol (and thus needs a cryptographic-strength guarantee) or it's not
(in which case whatever is fine).

I don't see what cert validation directly solves here. After all, the
bad guy can get certs signed, too. Why would it matter if the CN is
different if the CN isn't checked?

In the certificate, the "to-be-signed" tbsCertificate subfield is the
only part directly covered by the signature. Is it possible that an
attacker can modify unused bytes, or append any additional junk in the
part that's not signed? For example, it looks like an RSA signature (RFC
2313 PKCS #1 v 1.5) might admit some nul prefix bytes (it's an integer).
It wouldn't take many modifiable bytes to be able to engineer an
arbitrary FNV-1a value.

Of course the trusted_cas type remains trivially collidable.

- Marsh