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

Michael D'Errico <mike-list@pobox.com> Sun, 29 November 2009 17:02 UTC

Return-Path: <mike-list@pobox.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 19D0D3A68C8 for <tls@core3.amsl.com>; Sun, 29 Nov 2009 09:02:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.514
X-Spam-Level:
X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 VOvc9xOxTRoI for <tls@core3.amsl.com>; Sun, 29 Nov 2009 09:02:01 -0800 (PST)
Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id D98E43A67FD for <tls@ietf.org>; Sun, 29 Nov 2009 09:01:59 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id B0D7EA2E46 for <tls@ietf.org>; Sun, 29 Nov 2009 12:01:52 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=7Qpt/+lsN1t8 HHs0rLlH7m/gaeU=; b=KNEL0Wj+53H+ToGgOj6Ume5pHWFoNc+eN0WDq9OZDXew qJUHh1jWjiynmPQmSv0UPTzO+/GydAR9Ra4ZUQYsrBLzkJ7oUZWAJOMw/YmI3RRB nPf+ogHqSMr+BLJPhq3zoFMQuY1EGuw25jMfRUy3dkSmYQ2HwoHpidW/kNKsqOQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=hGqQfX 5G3jT6UbUP7WmrCwKc5puFSlKGO1PyTS/Z2sIhstgyBDYYEW9Lf5fKIfAnJEnc0/ XljN7hHfc01FeBB+kl0bAnyrWItNtkIA9sJ0CSm0d41BvJzg/6OD6Pr1/gdXKVx5 p70hNQYzrhVB3xiw/RyYCFIylJL8S7G5fI/YM=
Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id AC0FEA2E45 for <tls@ietf.org>; Sun, 29 Nov 2009 12:01:52 -0500 (EST)
Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 20DFFA2E44 for <tls@ietf.org>; Sun, 29 Nov 2009 12:01:51 -0500 (EST)
Message-ID: <4B12A95E.6040402@pobox.com>
Date: Sun, 29 Nov 2009 09:03:26 -0800
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
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> <4B1205AC.3060106@jacaranda.org>
In-Reply-To: <4B1205AC.3060106@jacaranda.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: E440A948-DD08-11DE-849E-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com
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 17:02:02 -0000

David-Sarah Hopwood wrote:
> 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.

I meant "well-formed", not valid, sorry.  It is plausible to think that
a peer might ignore an empty Finished message, if you believe it can be
broken in the way that would allow the theoretical attack to succeed.

Making the "fake_length" extend beyond the end of the PreviousVerifyData
completely solves this since it would cause the peer to read parts of
the subsequent valid messages into the fake Finished message.  Thus the
Certificate message would be lost, making it impossible for the handshake
to succeed.

And if that doesn't convince you, would you agree that changing the length
wouldn't hurt anything?  If so, then you can appease me by making it
0xFFFFFF instead of zero.

Mike