Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance
Michael D'Errico <mike-list@pobox.com> Tue, 10 November 2009 04:58 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 DD1FD3A6915 for <tls@core3.amsl.com>; Mon, 9 Nov 2009 20:58:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level:
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 8hrMXqhfBYd9 for <tls@core3.amsl.com>; Mon, 9 Nov 2009 20:58:46 -0800 (PST)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id E8F253A67CF for <tls@ietf.org>; Mon, 9 Nov 2009 20:58:44 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id C86CA7A389 for <tls@ietf.org>; Mon, 9 Nov 2009 23:59:10 -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=6Rv8739VjmaQ gELgB8HyuNRiN2g=; b=wisd/c9ybgAUfwPuCvWQbbtBKRcAHcnq25lT1FrNWjSZ PmsvuUZbRsRpv+cJJQBjZoNiA3JCiODEMScn43pNWmUIbFmMkwDx8VMX509B1tc7 d76BfIlq9dSUJZCW8ZzIIh3KE/ytgbJq0YfwX0YzlKuV2QEsQsExZcypzWR6j4I=
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=DB8Oo8 uX0Uq/Jv2X5RCHgm5uAcMP4DYuXXK92jnAlvEprl9Yf4f5EDX8lM92M0GWKF6D6s /KDQEaFVGshqLuh3L1dHkZLLTcmAHnO5BlKvdcOmtmMbm5rA8unDe6khQrWOtifV NmgZ2NB2daTbloVl6v3XVO7zxgU5V5ocTAUZw=
Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id C5D977A388 for <tls@ietf.org>; Mon, 9 Nov 2009 23:59:10 -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-quonix.pobox.com (Postfix) with ESMTPSA id 3A81E7A387 for <tls@ietf.org>; Mon, 9 Nov 2009 23:59:10 -0500 (EST)
Message-ID: <4AF8F363.2030201@pobox.com>
Date: Mon, 09 Nov 2009 21:00:19 -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: <200911092152.nA9LqVkW000963@fs4113.wdf.sap.corp>
In-Reply-To: <200911092152.nA9LqVkW000963@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: C8AF8E54-CDB5-11DE-A7B1-7B3EEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com
Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance
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: Tue, 10 Nov 2009 04:58:47 -0000
> As previously described in another message, the current spec has a > requirement that additonal application data may be arbitrarily > interleaved with a renegotiation handshake. I think this requirement > makes a security assessment of the protocol impossible for changing > identities. If your TLS API was able to tell you exactly where in the application data stream a renegotiation has completed successfully, you would be able to apply the original security parameters to the data received prior to the renegotiation, and then switch to the new parameters for the data received after the renegotiation. That would catch the MITM attack being discussed now. > Personally, I would it find much cleaner if the semantics for the > renegotiation would require the TLS peers to suspend transmission > of application data while performing TLS renegotiation, > i.e. > > the client must not send any application data between > ClientHello and the client's Finished message > > the server must not send any application data between > ServerHello and either no_renegotiation alert or > the server's Finished message > > the client must drop all application data received > between ServerHello and either no_renegotiation alert > or the server's Finished message > > the server must drop all application data received > between the ClientHello and the client's Finished message When I first implemented TLS, the only reason I could envision for renegotiation was to refresh the symmetric keys, so I made it work asynchronously. I wrote about it in this message: http://www.ietf.org/mail-archive/web/tls/current/msg04042.html With this design, application data can flow at nearly full speed while a renegotiation is taking place. Requiring all data to stop flowing during a renegotiation, may be unnecessary in some situations. I do see however, that data probably needs to stop flowing after sending a Finished message until receiving the peer's Finished message, but that affects only one direction and last for one round trip, not two. When you add changing client credentials to the mix, then data flow probably has to stop, but that is really an application-level decision. Also silently dropping data never seems like the right thing to do IMHO. > Are there currently applications that actively abuse the possibility > provided by the spec to interleave application data and handshake > messages of a TLS renegotiation handshake (provided that the > TLS implementation that (a) they're using and (b) they're talking > to actually allow this. The fact that the spec says so, doesn't > mean that everyone has implemented it in this fashion (since it > is complex,difficult and possibly insecure)? Yes, see the above referenced message. But I don't agree that it's abuse since that is what the spec. says to do. Mike
- [TLS] draft-rescorla-tls-renegotiate and MITM res… Yair Elharrar
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yoav Nir
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yoav Nir
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Dr Stephen Henson
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yair Elharrar
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yoav Nir
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Nicolas Williams
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… David-Sarah Hopwood
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… David-Sarah Hopwood
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yair Elharrar
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yoav Nir
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Nicolas Williams
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… David-Sarah Hopwood
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Michael D'Errico
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Nicolas Williams
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Nicolas Williams
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Steve Dispensa
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… David-Sarah Hopwood
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Peter Saint-Andre
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yoav Nir
- Re: [TLS] To API or not Bill Frantz
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Michael D'Errico
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- [TLS] RC4+3DES rekeying - long-lived TLS connecti… Martin Rex
- Re: [TLS] RC4+3DES rekeying - long-lived TLS conn… David-Sarah Hopwood
- Re: [TLS] RC4+3DES rekeying - long-lived TLS conn… Peter Saint-Andre