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

Yoav Nir <ynir@checkpoint.com> Mon, 09 November 2009 13:53 UTC

Return-Path: <ynir@checkpoint.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 3B26C3A6AE5 for <tls@core3.amsl.com>; Mon, 9 Nov 2009 05:53:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 aueFDR+nt2dM for <tls@core3.amsl.com>; Mon, 9 Nov 2009 05:52:59 -0800 (PST)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0142E3A6A78 for <tls@ietf.org>; Mon, 9 Nov 2009 05:52:58 -0800 (PST)
X-CheckPoint: {4AF81BC5-6-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id EDAC229C008; Mon, 9 Nov 2009 15:53:23 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id CCC8E29C007; Mon, 9 Nov 2009 15:53:23 +0200 (IST)
X-CheckPoint: {4AF81BC5-0-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nA9DrNc6007395; Mon, 9 Nov 2009 15:53:23 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 9 Nov 2009 15:53:26 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Marsh Ray <marsh@extendedsubset.com>
Date: Mon, 09 Nov 2009 15:53:21 +0200
Thread-Topic: [TLS] draft-rescorla-tls-renegotiate and MITM resistance
Thread-Index: AcphRAKJsW4FhNJwTuKJvS/5iM4a1Q==
Message-ID: <B1F20B37-462E-4224-9536-3DBF1B080831@checkpoint.com>
References: <CE2A65CAAFE55048BA6682475F9A7DBF5EA6E59A16@ACLMAIL01.corp.audiocodes.com> <4AF81CFF.8010803@extendedsubset.com>
In-Reply-To: <4AF81CFF.8010803@extendedsubset.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/signed; micalg="sha1"; boundary="Apple-Mail-38-294727374"; protocol="application/pkcs7-signature"
MIME-Version: 1.0
Cc: "tls@ietf.org list" <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
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 13:53:00 -0000

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?
>>
>> Since the MITM handles all traffic between the real client and real
>> server, it could add a fake extension to the 2nd ClientHello with its
>> original verify_data, and empty the returned extension in the
>> ServerHello.
>
> A valid concern, which I believe is addressed by the fact that the
> 'Finished' message in TLS contains a MAC which covers extensions  
> present
> on the Client and Server Hellos.
>
> IIRC, earlier SSLs did not cover extensions with a MAC.

I think SSLv3 did not allow for client extensions at all, and TLSv1.0  
already covered everything.

>
>> In addition, until such time that all clients in the world start
>> supporting this extension (e.g. kiosks in airports), servers will
>> have to support backward compatibility.
>
> It will be a trade-off for each server admin to weigh and decide their
> policy. I suspect many admins will prefer not to allow insecure
> connections from unpatched airport kiosks.

I suspect you have a way too optimistic view of administrators.  
Currently exactly 0% of browsers are patched. It will be years before  
even 50% or browsers are patched.

Yoav