Re: [TLS] Verify data in the RI extension?

David-Sarah Hopwood <david-sarah@jacaranda.org> Sun, 29 November 2009 05:25 UTC

Return-Path: <djhopwood@googlemail.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 5EF8A3A687B for <tls@core3.amsl.com>; Sat, 28 Nov 2009 21:25:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 wJFLK+-9ECxB for <tls@core3.amsl.com>; Sat, 28 Nov 2009 21:25:15 -0800 (PST)
Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id 004EC3A672E for <tls@ietf.org>; Sat, 28 Nov 2009 21:25:14 -0800 (PST)
Received: by ewy7 with SMTP id 7so3214265ewy.28 for <tls@ietf.org>; Sat, 28 Nov 2009 21:25:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=An5IydWJXapKhpt5zYQjxhL0YGFSfZGGQCalz/CVGzk=; b=QIA8RwRC/3t03jhhKD82nz1yTfMFLJo37nXyltMk+t0Jh0R4Vf6UfRa1zDkff809Z7 cecuJO5i+VSRCXmYGEP9joEMjACA65Ap+7/c/FvDvPlWJCaFS/e8XURe0MtW/pPv9BaQ eb5/DYhXRyKpmsVR4bZnfdnLShIuS1oKHAOzY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=pzTeia3qxUb4sm/zrQnheY1dZWz8hG2JxEg7US0XNgk9Mmtp5qf5c6sL/uSFvw11a0 4LYLAqJjyYsOtyfPA9g12/aZI292l744EZQcCEp3sFM303VAR/XLFhIRf8ktSPC9HQhG KW/kMZeWTtTnFzOwcamH7yQzA8YZ2MfRxmdSY=
Received: by 10.216.85.69 with SMTP id t47mr915132wee.107.1259472305268; Sat, 28 Nov 2009 21:25:05 -0800 (PST)
Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id t12sm7356390gvd.5.2009.11.28.21.25.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 28 Nov 2009 21:25:04 -0800 (PST)
Sender: David-Sarah Hopwood <djhopwood@googlemail.com>
Message-ID: <4B1205AC.3060106@jacaranda.org>
Date: Sun, 29 Nov 2009 05:25:00 +0000
From: David-Sarah Hopwood <david-sarah@jacaranda.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: tls@ietf.org
References: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> <C7355261.6BB2%stefan@aaa-sec.com> <20091127151113.BDEF16C3795@kilo.networkresonance.com> <4B10E225.4010501@jacaranda.org> <4B117AF2.20703@pobox.com> <4B11C156.7060204@jacaranda.org> <4B11FBF8.8080400@pobox.com>
In-Reply-To: <4B11FBF8.8080400@pobox.com>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------enig952F11093D7BA23558899837"
Subject: Re: [TLS] Verify data in the RI extension?
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: Sun, 29 Nov 2009 05:25:16 -0000

Michael D'Errico wrote:
> David-Sarah Hopwood wrote:
>> Michael D'Errico wrote:
>>> David-Sarah Hopwood wrote:
[...]
>>>> That potential weakness can be avoided by encoding the data to be added
>>>> into the hash as follows:
>>>>
>>>>    struct {
>>>>        enum { fake_finished(20) } fake_handshake_type;
>>>>        enum { zero(0), (2^24-1) } fake_length;
>>>>        opaque previous_client_verify_data<12..255>;
>>>>        opaque previous_server_verify_data<12..255>;
>>>>    } PreviousVerifyData;
>>> I like the direction this is going, but think that using a length of
>>> zero doesn't quite patch the potential weakness.
>>
>> It does: as I said, for an implementation to be vulnerable it would
>> have to violate two existing 'MUST's -- failing to abort the handshake
>> on an out-of-order handshake message, and failing to check the
>> correctness of the verify_data in a Finished message. If it gets the
>> latter wrong, then it's clearly insecure anyway. What is sent after
>> the fake Finished message doesn't matter for avoiding this weakness.
> 
> The theoretical weakness, as I understand it, is that inserting the
> previous verify_data directly into the handshake message stream would
> allow an attacker to send the previous data to an unpatched peer at the
> point where it would get inserted by a patched peer.  If (and it's a
> big if) that peer ignores that data, then the handshake has the possibility
> of completing.

The problem was that it wasn't possible to infer from the spec that
any possible extra handshake message at that point would cause an abort.
For the Finished message, it is possible to infer that it will.

> Your fix is to insert a "fake" header in front of the verify_data to make
> the attack impossible.  The problem with using a zero length is that the
> 4-byte header you inserted is a _valid zero-length Finished message_.

No, a valid Finished message would have to include a verify_data hash
(36 bytes in SSLv3; 12 bytes or more in TLS). It isn't plausible to
suppose that an implementation that is secure in other respects would
just ignore an extra Finished message of the wrong length and not
containing the right hash.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com