Re: TLS Renegotiation and HTTP/2 (#363)
Patrick McManus <pmcmanus@mozilla.com> Tue, 01 April 2014 03:54 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 E85521A0927 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 31 Mar 2014 20:54:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.289
X-Spam-Level:
X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 3MsJSIZVK459 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 31 Mar 2014 20:54:18 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id B6D461A0955 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 31 Mar 2014 20:54:18 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1WUplT-0005xj-Ta for ietf-http-wg-dist@listhub.w3.org; Tue, 01 Apr 2014 03:53:31 +0000
Resent-Date: Tue, 01 Apr 2014 03:53:31 +0000
Resent-Message-Id: <E1WUplT-0005xj-Ta@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <patrick.ducksong@gmail.com>) id 1WUplN-0005x3-IS for ietf-http-wg@listhub.w3.org; Tue, 01 Apr 2014 03:53:25 +0000
Received: from mail-qg0-f45.google.com ([209.85.192.45]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <patrick.ducksong@gmail.com>) id 1WUplM-00034H-2b for ietf-http-wg@w3.org; Tue, 01 Apr 2014 03:53:25 +0000
Received: by mail-qg0-f45.google.com with SMTP id j5so8403783qga.18 for <ietf-http-wg@w3.org>; Mon, 31 Mar 2014 20:52:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cAXuHR6UR5SuYoV66jIH3/IqyO0sslYtfqYoqjgyCJU=; b=UBLbCEtrGfwVF+Sniuro+bayhVAHDrcIraLy9hdqoonbDlyCazg51OXo2fKzACB+PD xFrEs/wwayaqTskF2tABjGtrp4ytyjjCyx8ItLFgt+sdMNSPcJbnlmbdzZAdbucoMhCw Mjn8FwLMgupkiaCTUzTfIQYWeZD/FcHrtc3Cnj1z5ET4RpO2kYazHGsD/68WSa54K9oq GNPFemIoaRsFxFXW2Tb2pzUweRicYiAlWQ/7OwqWDEHem8FEY0dJ6XM/+sbButmqkIp8 MTaOr6AHfHaYes7PICR/4fgWUSffvhIjtXs3cC7GSwjPaemDbaa5Dx2xe0BhpejzpUzZ vsVQ==
MIME-Version: 1.0
X-Received: by 10.140.107.136 with SMTP id h8mr11430440qgf.32.1396324378093; Mon, 31 Mar 2014 20:52:58 -0700 (PDT)
Sender: patrick.ducksong@gmail.com
Received: by 10.140.93.180 with HTTP; Mon, 31 Mar 2014 20:52:58 -0700 (PDT)
In-Reply-To: <CABkgnnUBAvSwejG_n_vjevDfhW5tv6xV1+W=KfKHNd2ufVv2oQ@mail.gmail.com>
References: <CABkgnnUBAvSwejG_n_vjevDfhW5tv6xV1+W=KfKHNd2ufVv2oQ@mail.gmail.com>
Date: Mon, 31 Mar 2014 23:52:58 -0400
X-Google-Sender-Auth: x0IQ7ZHm78IAcHq9i7TY8orfwVE
Message-ID: <CAOdDvNpMv-cNx+9mkahQuFEOgmrAxQEcGj4i5s7mzJzxjuQdZQ@mail.gmail.com>
From: Patrick McManus <pmcmanus@mozilla.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="001a113a56d48c2d2604f5f31a66"
Received-SPF: pass client-ip=209.85.192.45; envelope-from=patrick.ducksong@gmail.com; helo=mail-qg0-f45.google.com
X-W3C-Hub-Spam-Status: No, score=-4.0
X-W3C-Hub-Spam-Report: AWL=-2.101, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1WUplM-00034H-2b c91df2a67ca0e46b69762a07d313a16a
X-Original-To: ietf-http-wg@w3.org
Subject: Re: TLS Renegotiation and HTTP/2 (#363)
Archived-At: <http://www.w3.org/mid/CAOdDvNpMv-cNx+9mkahQuFEOgmrAxQEcGj4i5s7mzJzxjuQdZQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/22995
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>
Martin - when you put it like that.. yeach! I'm glad to hear you're not terribly enamored with option #1 - it seems like there are process dragons there and since it requires a new connection and handshake it isn't exactly winning any performance merit badges either. I was a little nervous about that road. At least given this presentation, #2 does take on a certain shine it hasn't really had in the past :). The quiescent issues can always be bounded with RST_STREAM if that's a priority for the application. It actually doesn't strike me as terribly complex to describe or implement. Operationally I think some degree of awkwardness is going to be connected to any of these. 3 and 4 seem considerably less desirable to me. 5 is ideal but insufficiently described for standardization :) -P On Mon, Mar 31, 2014 at 8:11 PM, Martin Thomson <martin.thomson@gmail.com>wrote: > 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