Re: [TLS] Opera 10.50 alpha snapshot with TLS Renego extension support

"Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com> Sat, 23 January 2010 17:47 UTC

Return-Path: <yngve@opera.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 E975C3A6992 for <tls@core3.amsl.com>; Sat, 23 Jan 2010 09:47:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.293
X-Spam-Level:
X-Spam-Status: No, score=-6.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, 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 f5LGJFBK66Gj for <tls@core3.amsl.com>; Sat, 23 Jan 2010 09:47:09 -0800 (PST)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 892D63A6961 for <tls@ietf.org>; Sat, 23 Jan 2010 09:47:09 -0800 (PST)
Received: from acorna.oslo.opera.com (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0NHhb9l030366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 23 Jan 2010 17:43:38 GMT
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "Wan-Teh Chang" <wtc@google.com>
References: <op.u6zq0sb5qrq7tp@acorna.oslo.opera.com> <e8c553a61001230909v3cf8ea42t9e900f00cb5554c1@mail.gmail.com>
Date: Sat, 23 Jan 2010 18:46:53 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com>
Organization: Opera Software AS
Message-ID: <op.u6zycfprqrq7tp@acorna.oslo.opera.com>
In-Reply-To: <e8c553a61001230909v3cf8ea42t9e900f00cb5554c1@mail.gmail.com>
User-Agent: Opera Mail/10.10 (Win32)
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Opera 10.50 alpha snapshot with TLS Renego extension support
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: Sat, 23 Jan 2010 17:47:11 -0000

On Sat, 23 Jan 2010 18:09:24 +0100, Wan-Teh Chang <wtc@google.com>; wrote:

> On Sat, Jan 23, 2010 at 7:08 AM, Yngve N. Pettersen (Developer Opera
> Software ASA) <yngve@opera.com>; wrote:
>> Hello all,
>>
>> Today Opera Software released a snapshot of Opera 10.50 alpha with  
>> support
>> for the TLS RenegotiationInfo extension.
>>
>> Server vendors should note the following:
>>
>>    * The RI extension is sent in all handshakes using extensions
>>    * The SCSV is only sent when we do not know if the server supports
>> extensions (implied: Patched servers always support the RI extension)
>
> Could you clarify one issue -- when you send SCSV, do you also
> send an empty RI extension?  Your second bullet point implies
> that when you send SCSV, you don't send any extension.  But

Whenever we send extensions the RI extension is sent.

Independently of this, if we do not know if the server supports or  
tolerates extensions we send the SCSV, but it can be sent in combination  
with the extensions. We send the SCSV during the initial feature probe  
(which may include sending extensions) and in the SSL v3/TLS v1.0 without  
extension modes.

> that contradicts your first bullet point, that you send the RI
> extension in *all* handshakes.

"in all handshakes [that uses] Extensions"

>>    * Against known patched servers Opera 10.50 will ONLY send Client  
>> Hellos
>> identifying TLS 1.2 as the highest supported version, and will abort  
>> ongoing
>> handshakes if it not already identifying with TLS 1.2. It will **NOT**  
>> fall
>> back to an older version if negotiation fails. Patched servers are  
>> assumed
>> to be version tolerant.
>
> I don't understand what you meant by "will abort ongoing handshakes
> if it not already identifying with TLS 1.2".

If we discover that the server supports RI during an initial handshake  
that did not identify TLS 1.2 as our highest supported version, we shut  
down the connection, and restart negotiation with a Hello identifying TLS  
1.2 as our highest version. Normally this means that upon first connection  
we will send a TLS 1.0 hello without extensions, get the RI extension  
back, shut down (which we would have anyway in most cases), and set up a  
new connection with the TLS 1.2 handshake. This can also occur for  
connection where we have previously determined version/extension  
configuration (which is usually cached for 4 weeks), but have never tested  
RI support. This procedure protects against potential version downgrade  
attacks.

>>    * It is a fatal error for a server (identified by hostname and port)  
>> to
>> first indicate support for RI, then later (in the same session) fail to
>> indicate support.
>
> In the same browsing session or in the same SSL session?

Same browsing session. Sorry for not being clear. We don't store a renego  
flag, but do cache the use of TLS 1.2 with extension. Since the eventual  
plan is to move to required RI support browse session only should be  
sufficient.

The scenario where this is likely to occur is multi-machine servers where  
not every machine has been updated.



-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************