TLS Renegotiation and HTTP/2 (#363)
Martin Thomson <martin.thomson@gmail.com> Tue, 01 April 2014 00:13 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769691A6F7B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 31 Mar 2014 17:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.012
X-Spam-Level:
X-Spam-Status: No, score=-7.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 1RPiTQG4QLwp for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 31 Mar 2014 17:13:39 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 56A6B1A08F2 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 31 Mar 2014 17:13:39 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1WUmJf-0006HT-FZ for ietf-http-wg-dist@listhub.w3.org; Tue, 01 Apr 2014 00:12:35 +0000
Resent-Date: Tue, 01 Apr 2014 00:12:35 +0000
Resent-Message-Id: <E1WUmJf-0006HT-FZ@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1WUmJZ-0006FS-Rv for ietf-http-wg@listhub.w3.org; Tue, 01 Apr 2014 00:12:29 +0000
Received: from mail-wi0-f178.google.com ([209.85.212.178]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1WUmJW-0002M2-AJ for ietf-http-wg@w3.org; Tue, 01 Apr 2014 00:12:29 +0000
Received: by mail-wi0-f178.google.com with SMTP id bs8so4204973wib.5 for <ietf-http-wg@w3.org>; Mon, 31 Mar 2014 17:11:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=FopKP5WobirBSvs+EBOMVixC+Rz5/9Eb8KIFLmW8CFA=; b=X2P3OAQru18x71lmWRZ5M7tWz5sOlGGh2iEoP0CXnPbzBjUgEwHY/0K8WXTthuAh9a itR6lR9kQV0r+mAh8ITpw3ZO74UShG2IWVNyOJFl1YzzVhbd2/JBncppnIf/lcDLzYkM G9mvZTLuCm2P3oTZ+TFitYAsb5INMCrvy6Y7YL5nJCulFDwCY/3ujQmTT9vWxVnhFBq3 rxcZGdODWcRvt9NO2JsUP92ZasKgRchm803Ddfe4nul4dnMESHsSOIrhZFV5vsWgAphl RKyJ+JS/2U66GQYZTq0uMPBbVnr74+ws4SY/yAP10BsBMNv3Qshq8mYpKJMyEhF28kLc bDMw==
MIME-Version: 1.0
X-Received: by 10.194.48.80 with SMTP id j16mr16415686wjn.44.1396311119653; Mon, 31 Mar 2014 17:11:59 -0700 (PDT)
Received: by 10.227.147.10 with HTTP; Mon, 31 Mar 2014 17:11:59 -0700 (PDT)
Date: Mon, 31 Mar 2014 17:11:59 -0700
Message-ID: <CABkgnnUBAvSwejG_n_vjevDfhW5tv6xV1+W=KfKHNd2ufVv2oQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=209.85.212.178; envelope-from=martin.thomson@gmail.com; helo=mail-wi0-f178.google.com
X-W3C-Hub-Spam-Status: No, score=-4.5
X-W3C-Hub-Spam-Report: AWL=-1.775, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1WUmJW-0002M2-AJ 6e9fb5c3497d538094a6bcdb1c076b88
X-Original-To: ietf-http-wg@w3.org
Subject: TLS Renegotiation and HTTP/2 (#363)
Archived-At: <http://www.w3.org/mid/CABkgnnUBAvSwejG_n_vjevDfhW5tv6xV1+W=KfKHNd2ufVv2oQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/22989
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
In my other email today, I've listed the items that are outstanding, of which I identify 6 issues that could result in disruptive changes to the protocol if we decide to act on them [1]. Of those, I think that TLS renegotiation is only the issue that fixes something we've actually broken. Broken, the sense that if we don't do something about this issue, we've broken a feature that some people rely on. Importantly, this is broken in a way for which the only real recourse is to revert to HTTP/1.1. (Transfer-Encoding #445 arguably introduces a feature regression too. But it's a regression that can be handled trivially by spending bytes. It might be reasonable to say that given the degree to which Transfer-Encoding is used today, the odds that we are creating incentive to stay on HTTP/1.1 is lower.) Relying on renegotiation for re-keying (to avoid key exhaustion) seems like a non-problem. We already require the creation of new connections when stream IDs run out. It does mean that extremely large requests or responses (broadly, anything longer than 2^64-1 TLS records, though probably less if the cipher suite requires re-keying earlier) cannot be carried at all. The main issue here is client authentication. I see several ways out: 1. Pursue http://tools.ietf.org/html/draft-thomson-httpbis-catch-00 or something like it to the bitter end. I don't see a way that we can do this without creating a new normative reference, unfortunately, and that work is clearly half-baked. 2. Allow for some very limited form of renegotiation for the client authentication use case. This might mean requiring that MAX_CONCURRENT_STREAMS be wound back to 1 at the server before renegotiation is triggered. This avoids the dependency issue, and might work for the use cases in question, but the cost in complexity and loss of concurrency is extreme to the point that option 3 starts looking good. 3. Force those using client authentication to stay on HTTP/1.1. We basically get this for free if we intend to pretend that this issue doesn't exist. I tend to think that this would be a bad outcome though. 4. Resurrect the CREDENTIAL frame from SPDY. My understanding of this mechanism is that it would be non-trivial to add this to the protocol. It is quite a flexible mechanism, but one with significant costs. This relies on RFC 5705 (TLS extractor) support, which is not universally supported in the various TLS stacks that are commonly used. It also requires a new setting and modifications to the HEADERS frame. 5. Something else that I haven't thought of yet. Does anyone have a way forward to recommend? My primary motivation here is getting HTTP/2 done. [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1292.html
- TLS Renegotiation and HTTP/2 (#363) Martin Thomson
- Re: TLS Renegotiation and HTTP/2 (#363) Patrick McManus
- Re: TLS Renegotiation and HTTP/2 (#363) Yoav Nir
- Re: TLS Renegotiation and HTTP/2 (#363) Ilari Liusvaara
- Re: TLS Renegotiation and HTTP/2 (#363) Yoav Nir
- Re: TLS Renegotiation and HTTP/2 (#363) Ilari Liusvaara
- Re: TLS Renegotiation and HTTP/2 (#363) Yoav Nir
- Re: TLS Renegotiation and HTTP/2 (#363) Martin Thomson
- Re: TLS Renegotiation and HTTP/2 (#363) Yoav Nir
- Re: TLS Renegotiation and HTTP/2 (#363) Martin Thomson
- Re: TLS Renegotiation and HTTP/2 (#363) Nicolas Mailhot
- Re: TLS Renegotiation and HTTP/2 (#363) Yoav Nir
- Re: TLS Renegotiation and HTTP/2 (#363) Martin Thomson