Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance

Martin Rex <mrex@sap.com> Mon, 09 November 2009 21:52 UTC

Return-Path: <mrex@sap.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 1AEBA3A6970 for <tls@core3.amsl.com>; Mon, 9 Nov 2009 13:52:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.861
X-Spam-Level:
X-Spam-Status: No, score=-5.861 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4]
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 UMKg17XalREg for <tls@core3.amsl.com>; Mon, 9 Nov 2009 13:52:09 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E0ABC3A68EF for <tls@ietf.org>; Mon, 9 Nov 2009 13:52:08 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA9LqW9b028623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 22:52:32 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911092152.nA9LqVkW000963@fs4113.wdf.sap.corp>
To: ynir@checkpoint.com
Date: Mon, 09 Nov 2009 22:52:31 +0100
In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A4EBF03@il-ex01.ad.checkpoint.com> from "Yoav Nir" at Nov 9, 9 11:05:59 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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: Mon, 09 Nov 2009 21:52:10 -0000

Yoav Nir wrote:
> 
> David-Sarah Hopwood wrote:
> 
> > Marsh Ray wrote:
> >
> > To prevent this attack, they don't have to disallow connections, only
> > renegotiations in which the extension is not used.
> 
> Even that can be further refined. You can freely renegotiate an
> authenticated session, as long as the renegotiation does not involve
> an identity change.
> 
> Obviously, if the first handshake include client authentication,
> any renegotiation that includes the same client cert is fine.


I whish there was a constraint that an identity/certificate that has
been established for a party during the TLS handshake MUST not change
during re-negotiation, but _none_ of the current SSL&TLS specs has
such a constraint, so the issue of identity change is currently
dumped as a responsibility onto the application.

I am certainly in favour of locking this down for the renegotiation.
I believe it is irresponsible to leave this un(der)specified as it is.

We can be lucky if the application performs an authentication at all.
since there currently is absolutely no signalling defined that would
tell an application reliably at which point of the stream a
renegotiation was completed, the app doesn't know (a) when to
perform an additional authentication and (b) where the data
from the previous session ends and where the next starts.

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.

There are software architectures where the server certificate is checked
in a callback style when processing the ServerCertificate handshake
message (both: PKI-verification and server endpoint identification),
Application data protected under the old encryption could be exchanged
after the processing of the ServerCertificate and before the
ChangeCipherSpec (i.e. protected under the old session), and
also between ChangeCipherSpec and Finished messages (protected
under the new session, but before the finished messages have verified).


The semantics for the initial TLS handshake on a connection are
*MUCH* cleaner (both full TLS handshake and session resume):
no application data may be exchanged before the finished messages
have been verified.

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

Since the original streams in both directions could have been used
in completely asynchronous fashion, both peers may have to get back
in sync for the renegotiation, recognizing that they're in sync by
receiving the first handshake message (ClientHello/ServerHello).

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)?


-Martin