Re: [TLS] tls 1.3: renegotiation

Nikos Mavrogiannopoulos <nmav@redhat.com> Tue, 29 July 2014 07:27 UTC

Return-Path: <nmav@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2F31A026A for <tls@ietfa.amsl.com>; Tue, 29 Jul 2014 00:27:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-q_u7Qmy7ya for <tls@ietfa.amsl.com>; Tue, 29 Jul 2014 00:27:42 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5BC21A009E for <tls@ietf.org>; Tue, 29 Jul 2014 00:27:42 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6T7RecB007481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 29 Jul 2014 03:27:40 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6T7RcVU008027 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2014 03:27:40 -0400
Message-ID: <1406618858.31179.4.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 29 Jul 2014 09:27:38 +0200
In-Reply-To: <CABkgnnWrwqKFfxSbbv95wK1hveTFzKwO7wUJnGJ4usvrFmuN7g@mail.gmail.com>
References: <7C3D5CF9-2B17-4953-A13D-C5E7226D13E7@ieca.com> <CABqy+so=yV9Gp8aCp3cJ8wQRmd6JC-J9raEzgw1c1UDdFT2=JQ@mail.gmail.com> <CABkgnnX4zU8kxKK=4HTyFyX-uxpujEkNcXfcDmt0CHwfF+q-BA@mail.gmail.com> <CABqy+spuvWmrxgznzA2dZB-4PD0QffdtaGihD-D6CNTM2ruH5g@mail.gmail.com> <CABkgnnWrwqKFfxSbbv95wK1hveTFzKwO7wUJnGJ4usvrFmuN7g@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tEyI6NIvFFo7ulGYhZdRH9os7s8
Cc: "TLS@ietf.org \(tls@ietf.org\)" <tls@ietf.org>
Subject: Re: [TLS] tls 1.3: renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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/options/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, 29 Jul 2014 07:27:44 -0000

On Mon, 2014-07-28 at 16:20 -0700, Martin Thomson wrote:

> > Renegotiation is a particularly elegant solution to several problems.
> > It requires little extra code beyond what is already used to perform
> > the initial handshake, and adding a (correctly designed) channel
> > binding as input to the renegotiation process will add the security
> > properties that some API and application developers had previously
> > expected renegotiation to provide.
> It might be conceptually elegant, but it's certainly not free.  Even
> within NSS, the number of "if we are renegotiating" branches is pretty
> large.
> 
> And fixing NSS is relatively easy.  It's the externalities
> renegotiation creates that are the larger problem.  Because API and
> application developers don't look for particular properties, the
> problem is with the assumptions, once of which is generally
> immutability of various properties.

Then please fix the provided by NSS API to make these assumptions
explicit to the applications rather than arguing to change the protocol
for everyone. 

regards,
Nikos