Re: [TLS] tls 1.3: renegotiation

Andrei Popov <Andrei.Popov@microsoft.com> Mon, 28 July 2014 22:24 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 B4EB91A0304 for <tls@ietfa.amsl.com>; Mon, 28 Jul 2014 15:24:14 -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 2wS9rZk3mWkm for <tls@ietfa.amsl.com>; Mon, 28 Jul 2014 15:24:12 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5983D1A028E for <tls@ietf.org>; Mon, 28 Jul 2014 15:24:12 -0700 (PDT)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB418.namprd03.prod.outlook.com (10.141.92.13) with Microsoft SMTP Server (TLS) id 15.0.995.14; Mon, 28 Jul 2014 22:24:10 +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.0995.014; Mon, 28 Jul 2014 22:24:10 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Martin Thomson <martin.thomson@gmail.com>
Thread-Topic: [TLS] tls 1.3: renegotiation
Thread-Index: AQHPpPeOOHAiusOfmU2fGY+VxmMv6puxMxAAgAS4VbCAABkIgIAADBzg
Date: Mon, 28 Jul 2014 22:24:09 +0000
Message-ID: <52de31491a51434ca4dc6cbbdda1d004@BL2PR03MB419.namprd03.prod.outlook.com>
References: <7C3D5CF9-2B17-4953-A13D-C5E7226D13E7@ieca.com> <CABqy+so=yV9Gp8aCp3cJ8wQRmd6JC-J9raEzgw1c1UDdFT2=JQ@mail.gmail.com> <da5c2db0d5c248d196333718e5674685@BL2PR03MB419.namprd03.prod.outlook.com> <CABkgnnU5dg3icMwOZ95nY-L=LP0yNB-dU5t5KUVOC1WdfsL4zw@mail.gmail.com>
In-Reply-To: <CABkgnnU5dg3icMwOZ95nY-L=LP0yNB-dU5t5KUVOC1WdfsL4zw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:ed31::2]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 0286D7B531
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(199002)(189002)(377454003)(24454002)(74316001)(106116001)(81542001)(79102001)(105586002)(64706001)(21056001)(99286002)(80022001)(20776003)(85306003)(4396001)(106356001)(81342001)(95666004)(76176999)(86612001)(33646002)(110136001)(46102001)(107046002)(92566001)(93886003)(54356999)(19580405001)(31966008)(19580395003)(83072002)(83322001)(87936001)(50986999)(74502001)(77982001)(101416001)(85852003)(76482001)(76576001)(86362001)(2656002)(99396002)(74662001)(108616002)(24736002)(3826002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB418; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HraFk-EDQSLt2D5NKcCpvBpg2U4
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: Mon, 28 Jul 2014 22:24:14 -0000

> Client authentication is still possible, it just has to come in the opening handshake.  Your concern is spontaneous client authentication.
Correct, I am concerned because a lot of sites choose to serve landing pages without client auth, and then request client auth with an appropriate cert once the user navigates to a particular protected resource. This scenario works today, but seems to be hard (or impossible?) to implement when TLS1.3 and HTTP/2 are negotiated.

> HTTP/2 forbids renegotiation entirely, but permits it before HTTP/2 starts (to allow for client certificate confidentiality, if that is desired).

> That means that for HTTP/2 at least, the need isn't there.  They are already looking for alternatives.
Are you saying that because HTTP/2 designers chose to ban renegotiation, the customers no longer need to perform TLS client auth in the middle of a connection? Perhaps I'm missing this point.

> And it's not that alternatives don't exist, it's more the case that we disagree on the viability aspects, I think.
The alternatives would need to address all the combinations of TLS and HTTP versions (and I believe the alternatives proposed so far don't). Also, there should be some way to encapsulate the alternatives such that sites don't need to fork client auth code for different TLS + HTTP version combinations. Next, it is not desirable to add latency compared with the existing solution. And if we can get this to work for all application protocols (not just HTTP), even better. Hopefully the result will prove to be worth the design and implementation effort:).

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Monday, July 28, 2014 2:02 PM
To: Andrei Popov
Cc: Robert Ransom; Sean Turner; TLS@ietf.org (tls@ietf.org)
Subject: Re: [TLS] tls 1.3: renegotiation

On 28 July 2014 13:11, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
> It looks like one would need to deploy  both TLS1.3 and HTTP/2 at the same time. Once TLS 1.3 and HTTP/2 are deployed, the way a site implements TLS client auth will depend on the combination of TLS version and HTTP version negotiated:
> TLS1.3 + HTTP/2 -> New-style TLS client auth (TBD).
> TLS1.3 + HTTP/1.1 -> No way to support TLS client auth?
> TLS1.2 + HTTP/2 -> No way to support TLS client auth?
> TLS1.2 + HTTP/1.1 -> TLS client auth via renegotiation.

Client authentication is still possible, it just has to come in the opening handshake.  Your concern is spontaneous client authentication.

HTTP/2 forbids renegotiation entirely, but permits it before HTTP/2 starts (to allow for client certificate confidentiality, if that is desired).

That means that for HTTP/2 at least, the need isn't there.  They are already looking for alternatives.

And it's not that alternatives don't exist, it's more the case that we disagree on the viability aspects, I think.