[TLS] Comments on draft-rescorla-tls-renegotiate

Nicolas Williams <Nicolas.Williams@sun.com> Fri, 13 November 2009 01:05 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 7A4513A69E1 for <tls@core3.amsl.com>; Thu, 12 Nov 2009 17:05:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.02
X-Spam-Level:
X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[AWL=0.026, 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 D9gctWrs7O9z for <tls@core3.amsl.com>; Thu, 12 Nov 2009 17:05:25 -0800 (PST)
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 86CA73A6A9A for <tls@ietf.org>; Thu, 12 Nov 2009 17:05:25 -0800 (PST)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAD15sJc008098 for <tls@ietf.org>; Fri, 13 Nov 2009 01:05:54 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 nAD15sbb038359 for <tls@ietf.org>; Thu, 12 Nov 2009 18:05:54 -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 nAD0sJT0018961; Thu, 12 Nov 2009 18:54:19 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAD0sJLE018960; Thu, 12 Nov 2009 18:54:19 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Thu, 12 Nov 2009 18:54:19 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20091113005419.GQ1105@Sun.COM>
References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com>
User-Agent: Mutt/1.5.7i
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: [TLS] Comments on draft-rescorla-tls-renegotiate
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: Fri, 13 Nov 2009 01:05:26 -0000

Comments:

1) The rest of this comment can be ignored if the use of protocol
   extensions in draft-rescorla-tls-renegotiate is deemed to not be a
   problem.

   I believe this problem can be fixed without using protocol extensions
   at all.  All that has to be done is this: for re-negotiations the
   Finished message computation changes from this:

    PRF(master_secret, finished_label, Hash(handshake_messages))
       [0..verify_data_length-1];

   to:

    PRF(master_secret, finished_label,
	    Hash(handshake_messages || outer_connection_client_finished))
       [0..verify_data_length-1];

   where outer_connection_client_finished is the client Finished message
   for the previous/old/outer TLS connection

   There is no need to signal this!

   Either both, the client and the server will do this, or not do it, in
   which case the Finished messages will check out on both sides, or one
   will do it and the other won't, in which case the Finished messages
   will fail to check out on both sides.  If there's a MITM and the
   client and server both do this, then the MITM will be detected.

   I.e., channel binding is the solution, but there's no need to
   negotiate it -- the server wouldn't accept re-negotiation from
   clients that don't support the fix anyways.

   If there's no need to negotiate the fix, then there's no need to use
   Hello extensions.

   Also, this scheme allows both, the client and the server, to securely
   determine whether the other implemented the fix or not.  This is
   potentially a good or bad thing, depending on your point of view,
   since it allows for implementations to have an option to fallback on
   insecure behavior.

2) I believe the I-D, if the fix is not modified, should have the
   following INFORMATIVE text added:

   "
   This solution is akin to channel binding [RFC5056] using the
   'tls-unique-for-telnet' channel binding type
   [I-D.altman-tls-channel-bindings].  This is not a generic
   channel binding facility however.
   "

   RFC5056 and draft-altman-tls-channel-bindings-07.txt should be
   added as informative references.  (draft-altman-tls-... is currently
   listed as a normative reference.)


Nico
--