Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance
Martin Rex <mrex@sap.com> Mon, 09 November 2009 16:46 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 36C003A6B80 for <tls@core3.amsl.com>; Mon, 9 Nov 2009 08:46:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.134
X-Spam-Level:
X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.115, 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 PJlvHXTclwjI for <tls@core3.amsl.com>; Mon, 9 Nov 2009 08:46:11 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 105C63A6A29 for <tls@ietf.org>; Mon, 9 Nov 2009 08:46:10 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA9GkWmF002758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 17:46:32 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911091646.nA9GkW6n008821@fs4113.wdf.sap.corp>
To: ynir@checkpoint.com
Date: Mon, 09 Nov 2009 17:46:32 +0100
In-Reply-To: <B1F20B37-462E-4224-9536-3DBF1B080831@checkpoint.com> from "Yoav Nir" at Nov 9, 9 03:53:21 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
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 16:46:12 -0000
Yoav Nir wrote: > > On Nov 9, 2009, at 3:45 PM, Marsh Ray wrote: > > > Yair Elharrar wrote: > >> The proposed draft is intended to resolve an MITM attack scenario, > >> but is the new extension tamper-resistant? It is tamper resistent in the same fashion as the rest of SSL/TLS. No more, but also no less! > > > IIRC, earlier SSLs did not cover extensions with a MAC. Those that have this problem are not interoperable with a TLS+extensions handshake (which might be why some browsers added a handshake retry mechanism for a naked SSLv3 ClientHello. > > I think SSLv3 did not allow for client extensions at all, and TLSv1.0 > already covered everything. The problem with SSLv3 is, that the spec was finalized after the implementations had been shipped. :-| If I refer to SSLv3, I always base my assuption on the SSLv3 internet draft document from Nov 18, 1996 document, which was the starting point for TLS v1.0. It contains the following note at the top of page 24 (5.6.1.2. ClientHello): Forward compatibility note: In the interests of forward compatibility, it is permitted for a client hello message to include extra data after the compression methods. This data must be included in the handshake hashes, but must otherwise be ignored. Which means in principle that SSLv3 allows extensions to be used, and the extra data will be integrity protected by the finished messages of the handshake. If you look at the TLSv1.0 spec (rfc2246) and TLSv1.1 spec (rfc4346), neither contains extension data in the ServerHello in the base spec. Is there a reason why TLS extensions should _NOT_ be applicable to SSLv3 in just the same way they're applicable to TLSv1.0 and TLSv1.1 ? There may be SSLv3 servers out there that choke on extension data in the ClientHello. But that doesn't mean that one could not upgrade SSLv3 servers to support TLS extensions. The more interesting question is IMHO -- which TLS clients will choke when an SSLv3 server returns a ServerHello extension? spec-wise, a ServerHello extension is as unusual to SSLv3 as it is to TLSv1.0. -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