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