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