Re: [TLS] draft-ietf-tls-renegotation: next

Michael D'Errico <mike-list@pobox.com> Thu, 17 December 2009 23:34 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 BA5363A69D4 for <tls@core3.amsl.com>; Thu, 17 Dec 2009 15:34:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level:
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 Pr38o9D4l+xS for <tls@core3.amsl.com>; Thu, 17 Dec 2009 15:34:58 -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 8BD283A68A9 for <tls@ietf.org>; Thu, 17 Dec 2009 15:34:58 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id AF120A7621 for <tls@ietf.org>; Thu, 17 Dec 2009 18:34:43 -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=8ZHz6oSf2ZW7 MASpH7fmENVVnZ0=; b=LCH7L+v4OXpaEYQkAd1omF4XYhcshGAxeqOXltpCMCAb boXYRKqkmYpQQ2rNHVQXe1e/umm4KwOWyFtp9BLOsnC8Prekt4aZN6FF5VjJoMhZ uMoiOpISFQ3AHvPmF/P7EHc6a/xio8cjHx3T42TngSXkeO4aKqBPe9ewuS1ZgaY=
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=oSBjF1 6LP9XZYa49Cd00+rBd5l0yth7huBo1s6rhohKn4KTiWc09ECm8K1LoKH9SJ+CcXJ InOtNveJMjML2TFWDqOFrlBvqBk6nZ1bWmJ+pEEdQx6GUPpAW4+/CK5ThtvhC5hy /OTYa0/TGyPvFyoe1dVKpNPd69+kFIObNN+lQ=
Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id AB776A7620 for <tls@ietf.org>; Thu, 17 Dec 2009 18:34:43 -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 239FDA761F for <tls@ietf.org>; Thu, 17 Dec 2009 18:34:42 -0500 (EST)
Message-ID: <4B2AC077.4010506@pobox.com>
Date: Thu, 17 Dec 2009 15:36:23 -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: <200912162001.nBGK1K4I028293@stingray.missi.ncsc.mil> <200912162059.nBGKx7Sv017923@fs4113.wdf.sap.corp> <808FD6E27AD4884E94820BC333B2DB774F31F777D1@NOK-EUMSG-01.mgdnok.nokia.com> <6b9359640912171455j4c949defu25b5ad79348197da@mail.gmail.com>
In-Reply-To: <6b9359640912171455j4c949defu25b5ad79348197da@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: C11909E6-EB64-11DE-89A3-B34DBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com
Subject: Re: [TLS] draft-ietf-tls-renegotation: next
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: Thu, 17 Dec 2009 23:35:00 -0000

Kyle Hamilton wrote:
> .....  If we're going to force the implementors to
> save the hashes anyway, why should we take the risk of putting them
> out on the wire?  (To avoid a "chosen plaintext" attack... against a
> key and negotiation that's about to change?)

I was going to say, "The RI data sent over the wire is protected with
the same security as it was when it was in the Finished messages."

But actually, that's not entirely true; the client's Finished message
gets exposed on the server-to-client link in a renegotiation, where it
was previously hidden (due to different keys used in both directions).

Perhaps RI from server-to-client should just be the server's previous
Finished message, as I believe Bodo suggested weeks ago.

> (However, I do recognize that putting the prior hashes into an RI
> extension will cause them to be part of the final hash for Finished
> anyway, without requiring any changes in how the cryptographic system
> is set up.  I'm unhappy with this idea, though, because there are
> still MANY extension-agnostic clients and servers out there.  Clients
> won't send extensions if they don't have to, and servers won't show
> that they know about extensions unless the client shows exactly the
> extension they expect.)

Simply sending the prior hashes within RI extensions does not offer
any security whatsoever.  Both sides need to verify that what they
receive matches what they remember from the prior handshake.  This is
a known problem; a peer that forgets to check is still completely
vulnerable.

> If those hashes are saved by each peer (as would be required under
> this proposal), then it follows that since they're placed under
> separate cover by the Finished message, they're an appropriate input
> for the Renegotiation-Finished hash calculation.  Again, there's no
> reason to put them on the wire.

You're right that there is no need to put it on the wire, but then you
need to come up with a way to incorporate the old verify_data into the
renegotiation Finished message calculation.  Martin's draft suggests
one way to do that, though many seem to prefer to wait until the next
version of TLS to define that, since there will be lots of time to
design it properly.

Mike