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
- [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