Re: [TLS] Proposed text for removing renegotiation

Andrei Popov <Andrei.Popov@microsoft.com> Mon, 09 June 2014 18:50 UTC

Return-Path: <Andrei.Popov@microsoft.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 A60701A02D2 for <tls@ietfa.amsl.com>; Mon, 9 Jun 2014 11:50:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 PttVMA5VuQBS for <tls@ietfa.amsl.com>; Mon, 9 Jun 2014 11:49:59 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3AB91A029F for <tls@ietf.org>; Mon, 9 Jun 2014 11:49:58 -0700 (PDT)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) with Microsoft SMTP Server (TLS) id 15.0.954.9; Mon, 9 Jun 2014 18:49:56 +0000
Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.0954.000; Mon, 9 Jun 2014 18:49:56 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Martin Thomson <martin.thomson@gmail.com>, Nikos Mavrogiannopoulos <nmav@redhat.com>
Thread-Topic: [TLS] Proposed text for removing renegotiation
Thread-Index: AQHPefQqRTsIIFK8gk6N5dkaAVUiXZtVJ/UAgAEX8YCADnobgIABFBgAgAALywCAApynAIAAs6aAgAAEdjA=
Date: Mon, 9 Jun 2014 18:49:56 +0000
Message-ID: <fab4976db86243c5a02039866e3be457@BL2PR03MB419.namprd03.prod.outlook.com>
References: <CAFewVt65X1V6=A_HP_pcg=6nXNVFLxQmSsPB2rq1KvmGPRz+og@mail.gmail.com> <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <CACsn0cmcc6kXvOuqkZaDj7+QPdpY9qqQ58bs3s-JBGXdNJSZyw@mail.gmail.com> <CABcZeBPe45BM-uXd7DEBD_BBn=jhk8KkYB=facp+NMb2e4nBiw@mail.gmail.com> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <CABkgnnX5+fXNDy1o7Pu60rp8vSx7XfKbt337e_q=+3fb8fXHJw@mail.gmail.com>
In-Reply-To: <CABkgnnX5+fXNDy1o7Pu60rp8vSx7XfKbt337e_q=+3fb8fXHJw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e0:ee43::2]
x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
x-forefront-prvs: 02379661A3
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51444003)(24454002)(13464003)(199002)(189002)(377454003)(31966008)(101416001)(77096999)(33646001)(2656002)(76576001)(19580405001)(74662001)(4396001)(54356999)(83322001)(99286001)(99396002)(83072002)(74502001)(85852003)(15202345003)(21056001)(76176999)(79102001)(87936001)(86362001)(76482001)(80022001)(81342001)(77982001)(50986999)(20776003)(19580395003)(92566001)(64706001)(15975445006)(74316001)(81542001)(93886002)(46102001)(561944003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB419; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/H7QZfuZwC98MmF7AYqlaRgfTlSM
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Proposed text for removing 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: Mon, 09 Jun 2014 18:50:03 -0000

Hi Martin,

> The former we have decided to solve in HTTP.
 
Are you referring to these I-Ds:
http://tools.ietf.org/html/draft-thomson-httpbis-cant-00
http://tools.ietf.org/html/draft-thomson-tls-care-00

Httpbis-cant talks (rather vaguely) about using "realm" or "other challenge parameters" to select an appropriate client cert. I think client cert selection should be clearly specified before we can say that the mid-session client auth problem has been solved, and remove renegotiation from TLS 1.3.

It would be even better to solve this problem at the TLS layer, so that each application protocol does not need to come up with a separate solution. And avoiding the round-trips involved in establishing a TCP connection would be awesome, too. The current solution using renegotiation has both of these desirable properties.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson
Sent: Monday, June 9, 2014 11:17 AM
To: Nikos Mavrogiannopoulos
Cc: tls@ietf.org
Subject: Re: [TLS] Proposed text for removing renegotiation

On 9 June 2014 00:34, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
> Could somebody elaborate on what is that issue and why does it need to 
> be solved? (it is not even mentioned in the TLS 1.3 charter) As 
> someone who follows the mailing list that proposal comes out of the 
> blue with no context whatsoever.


I think that this has been covered in the thread, but piecemeal:

* Renegotiation is a major source of security issues, both of the "we screwed the TLS design up" sort and of the "my application didn't realize that these things could change" sort.  There is a clear desire to remove features that enable either sort of problem.

* Renegotiation is just more protocol complexity.  Removing it potentially makes implementations simpler.

I think that either might be sufficient justification for removing the feature.

However, a number of use cases depend on renegotiation to achieve their ends.  Of these, we have identified:

* mid-session client authentication, which uses renegotiation seems to only be used in HTTP

* very long-lived connections, which require renegotiation to re-key occasionally

The former we have decided to solve in HTTP.  As a side note, we just decided to forbid renegotiation in HTTP/2.

The latter can be addressed by my proposal, or any of a number of mechanisms.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls