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

Martin Rex <mrex@sap.com> Tue, 10 November 2009 22:57 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 172983A6B89 for <tls@core3.amsl.com>; Tue, 10 Nov 2009 14:57:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.149
X-Spam-Level:
X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 IUxANgKvlOLc for <tls@core3.amsl.com>; Tue, 10 Nov 2009 14:57:44 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id EF3AE3A6B7D for <tls@ietf.org>; Tue, 10 Nov 2009 14:57:43 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAAMw8xN014688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Nov 2009 23:58:08 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911102258.nAAMw6Ah002480@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com
Date: Tue, 10 Nov 2009 23:58:06 +0100
In-Reply-To: <4AF9DE40.60903@extendedsubset.com> from "Marsh Ray" at Nov 10, 9 03:42:24 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
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: Tue, 10 Nov 2009 22:57:45 -0000

Marsh Ray wrote:
> 
> Martin Rex wrote:
> 
> > If you lock down established identites, then I do not see a problem with this.
> 
> Really, it's the upper layers that define how 'identity' is to be
> interpreted. TLS may know that the certs on one end or the other is the
> same, but that is not the same as saying that the actual app-layer
> identities are interchangeable.

One can not blindly rely on apps to do authentication, let alone
do it consistently multiple times.  Therefore the default should
be exact identity match.


I think that an administrative change to the identity ought to have
an effect on TLS communication established with that identity/credentials,
or it is (a) a security problem and (b) a support nightmare.


If an apps protocol is so broken that it keeps running for weeks after
an administrative change but will fail a reboot, then this is a support
nightmare.


Similarly, if an application wants TLS to use OCSP and also wants
TLS to keep established session running for days or weeks ignoring
certificate expiration and revocation status, then something about
such an apps security requirements is fundamentally flawed.


> 
> >> 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.
> > 
> > Why Finished?  I think its everything following the ChangeCipherSpec.
> 
> For all the reasons that the Finished message was added to the protocol?
> 
> Hmmm, is app data allowed prior to the first finished message? No way,
> couldn't happen.


We're talking about renegotiation, not the initial handshake.
The current TLS spec contains a requirement that application data
can be arbitrarily interleaved with handshake message during
renegotiation.


Application data uses a different record type at the SSL/TLS record layer
than handshake messages.  The MAC for the finished messages covers
only the handshake messages, it entirely ignores all interleaved
application data records.
 


-Martin