Re: [TLS] TLS renegotiation issue

Nicolas Williams <Nicolas.Williams@sun.com> Thu, 05 November 2009 18:57 UTC

Return-Path: <Nicolas.Williams@sun.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 403F43A62C1 for <tls@core3.amsl.com>; Thu, 5 Nov 2009 10:57:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.015
X-Spam-Level:
X-Spam-Status: No, score=-6.015 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 T3UiihmL+hdW for <tls@core3.amsl.com>; Thu, 5 Nov 2009 10:57:23 -0800 (PST)
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 541793A68C3 for <tls@ietf.org>; Thu, 5 Nov 2009 10:57:23 -0800 (PST)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA5Ivkab006730 for <tls@ietf.org>; Thu, 5 Nov 2009 18:57:46 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nA5IvjOL014224 for <tls@ietf.org>; Thu, 5 Nov 2009 11:57:45 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA5IkG81009327; Thu, 5 Nov 2009 12:46:16 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5IkGne009326; Thu, 5 Nov 2009 12:46:16 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Thu, 5 Nov 2009 12:46:15 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20091105184615.GG1105@Sun.COM>
References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <d3aa5d00911051016p7a0cc508q2090b86de30a50d5@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d3aa5d00911051016p7a0cc508q2090b86de30a50d5@mail.gmail.com>
User-Agent: Mutt/1.5.7i
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS renegotiation issue
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: Thu, 05 Nov 2009 18:57:24 -0000

On Thu, Nov 05, 2009 at 10:16:11AM -0800, Eric Rescorla wrote:
> I now have a draft extension up at:
> 
> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt
> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml

Initial comments based on a brief skim:

 - Please add a normative reference to RFC5056.

 - There's no real need for the ServerHello to include both of the
   Finished messages from the outer TLS connection.  (I think there's no
   real need for the ServerHello to include either of them, actually,
   but I've not thought enough about that.)  But it's OK as is, of
   course.

 - You call for each TLS handshake to bind to the one immediately
   outside it.

   Would it be better to bind to the outer-most one instead?

   (In practice there's probably never more than one outer and one inner
   handshake, right?)

 - There is a way for clients to protect themselves even when servers
   don't implement this extension:

   a) clients MUST NOT ever send any application-level messages without
      TLS protection if they are willing to negotiate a TLS connection
      after sending any application-level messages,

   _and_,

   b) if a server requests re-negotiation then the client MUST ensure
      that the outer and inner TLS connection handshakes used a server
      certificate, and, specifically, the _same_ server certificate,
      otherwise the client MUST abort without ever completing the
      second/inner handshake.

   This should be stated as it is a helpful workaround that works
   without modifying the protocol.  It's not a generic solution, and
   it's a client-side-only solution, which is why it's highly desirable
   to apply the proposed channel binding solution instead.

 - Might as well update RFC5246 to indicate that the Finished messages
   for any connection MUST be exported to applications.  Better get this
   done now.

Nico
--