Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

Steve Dispensa <dispensa@phonefactor.com> Tue, 12 January 2010 15:42 UTC

Return-Path: <dispensa@phonefactor.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 D36473A67B7 for <tls@core3.amsl.com>; Tue, 12 Jan 2010 07:42:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.359
X-Spam-Level:
X-Spam-Status: No, score=-5.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24]
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 3RzU1NaYAX+O for <tls@core3.amsl.com>; Tue, 12 Jan 2010 07:42:37 -0800 (PST)
Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by core3.amsl.com (Postfix) with SMTP id EB27F3A680F for <tls@ietf.org>; Tue, 12 Jan 2010 07:42:36 -0800 (PST)
Received: from source ([204.13.120.8]) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKS0yYatRO2OcdqVpGxeoRP/nLNPm1SEvX@postini.com; Tue, 12 Jan 2010 07:42:35 PST
Received: from sevil-2k3-r2-1.sbs2.local ([10.10.10.91] RDNS failed) by pos-exch1.corp.positivenetworks.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Jan 2010 09:39:48 -0600
References: <201001121440.o0CEe7k1026688@fs4113.wdf.sap.corp> <4B4C928C.5050105@extendedsubset.com>
In-Reply-To: <4B4C928C.5050105@extendedsubset.com>
Mime-Version: 1.0 (Apple Message framework v1076)
Content-Type: text/plain; charset="us-ascii"; format="flowed"; delsp="yes"
Message-Id: <D0E89820-41D3-4263-9427-0FA0166F8CFC@phonefactor.com>
Content-Transfer-Encoding: 7bit
From: Steve Dispensa <dispensa@phonefactor.com>
Date: Tue, 12 Jan 2010 09:42:31 -0600
To: Marsh Ray <marsh@extendedsubset.com>
X-Mailer: Apple Mail (2.1076)
X-OriginalArrivalTime: 12 Jan 2010 15:39:48.0438 (UTC) FILETIME=[791A0F60:01CA939D]
Cc: "Kemp David P." <DPKemp@missi.ncsc.mil>, tls@ietf.org
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft
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: Tue, 12 Jan 2010 15:42:38 -0000

On Jan 12, 2010, at 9:17 AM, Marsh Ray wrote:

> Martin Rex wrote:
>>
>> There is absolutely _NO_ known security problem and no  
>> vulnerability for
>> a server to accept an initial handshake with the existing SSLv3,  
>> TLSv1.0,
>> TLSv1.1 or TLSv1.2 protocol, even when the ClientHello handshake
>> message does neither contain SCSV nor an empty extension RI.
>
> Baloney!
>
>> The possibility for an "attack" where an old client's renegotiation
>> handshake is proxied into the initial handshake of a server is of
>> no concern to the server.
>
> TLS is a network data security protocol. Both parties have an interest
> in the security of the connection.
>
> If a client has the attacker's data in his input buffer, then a
> legitimate server's handshake provides a certificate which the client
> interprets as authenticating the previous data, the attacker has  
> stolen
> the servers credentials!
>

FWIW, I believed as Martin did in the early days while we were trying  
to work out the implications of the attack, but I've come to believe  
that Marsh is right - letting a client get data into his input buffer  
that is subsequently authenticated by a legitimate server is obviously  
a bad thing, and there's enough vagueness in real implementations (and  
complete silence in documentation) that I would be shocked if someone  
weren't vulnerable to this attack.

Now, of course, it's a client attack at that point, not a server  
attack, so one might reasonably wonder whether it's the server's  
responsibility to defend against it. (A patched client that indicates  
support for safe renegotiation to a server that also supports it will  
defeat this attack, without the server doing anything special.)

Still, I think you can make an argument about total Internet security  
that says that servers shouldn't negotiate with unpatched clients.  
That obviously involves a giant trade-off in the short term, but don't  
be caught thinking that there is no security impact to agreeing to  
negotiate (as opposed to re-negotiate) with an unpatched client.

  -Steve