From nobody Fri Dec 18 01:34:28 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BC63A11CE for ; Fri, 18 Dec 2020 01:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lukasa-co-uk.20150623.gappssmtp.com 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 ZrLKR4m0H_zU for ; Fri, 18 Dec 2020 01:34:24 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BDCB3A11CD for ; Fri, 18 Dec 2020 01:34:24 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id h205so3787338lfd.5 for ; Fri, 18 Dec 2020 01:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lukasa-co-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fUjclPLfSAl2oAiaUdJ5ngZFhpGXlWo8JmUP65VCKic=; b=cPEuX1l3OX+O7yTmjB+Bo5eiyf1CdvfxdNSPITUmYD4/1nrzkqILiPr+YU0mF7rlX+ mav1Fty/3wBtswXlmOxBdLVHNoGLBAClNLlV3djvix/MHN5I1ZnPqTS9qfiLcdoPrj/S peQhYA42Ovitzc0fEK8hLeyZhpMbbvTopvj5uEdCWo5JqiBzAD+B92riGiWv5cMKOsA3 bNKKz+5iaflJX2/2L6AYWjjUeViM+YLbmp33Qg1X67xyjNHlgHCDnHbidMXjcEYjhPfz 7oJdICYlbP4TJBgitQ9Gf5SIWzJLS1Yn4Jk/OaK9r8NBlxzULIfpYS7FffXgSf5XWUz4 SASA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fUjclPLfSAl2oAiaUdJ5ngZFhpGXlWo8JmUP65VCKic=; b=gi4KXJck0vRX8SDSmf4b0zZuKTP0F+dAbN43zsl/oBK8q9HDIZOu9uAwik5A5BuL8G QC1RUWwQ44OaUXz5udtvZJgQwLwHan9YBxhmDOOX9BEf6T1knhI5T4IQaiEJpjeJGG1t F7IXy0V3nxDiEDdUtT5OJuyVA+ktEtvn4kKYnUKPb6tfEWyGjo8lBahdnGSRF8sr2wHt wZuURLAtA7YOAQl7EJr2dpPGDI+1uGUlAkh8aajD3cg4iUkbZ3zWQiISV96eKnOZxafv UPOxs3NwAWP8429OkLStpysjBUPJIo6D3D6tTrl95/5ZAjnwy66OBMP8E3by51maafMs i9VQ== X-Gm-Message-State: AOAM533kvKRh/PSAHCXlkm1UR8CCk4qey37cK6lV/38Vyiv5m+XCaP8t WON2Ygn3CZX1hcKkEdT4xEozB/g4oNdK++uBVK9IXw== X-Google-Smtp-Source: ABdhPJyRnFBZgURUqUeZtCpjZynNptxJ3LiqT9TSZCZEDDou/ZCC59FgvK8uOzGYvtBPiEaGdHWTLyNWiHNVaIV8YwM= X-Received: by 2002:ac2:5a50:: with SMTP id r16mr1219239lfn.195.1608284062100; Fri, 18 Dec 2020 01:34:22 -0800 (PST) MIME-Version: 1.0 References: <160703055132.9234.3055845983488231389@ietfa.amsl.com> In-Reply-To: From: Cory Benfield Date: Fri, 18 Dec 2020 09:34:11 +0000 Message-ID: To: Victor Vasiliev Cc: David Benjamin , "" , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] ALPS and TLS 1.3 half-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2020 09:34:27 -0000 On Wed, 16 Dec 2020 at 10:16, Cory Benfield wrote: > > On Fri, 11 Dec 2020 at 03:44, Victor Vasiliev wrote: > > > > Hi Cory, > > > > I am not sure there is a big difference between ALPN and ALPS in that r= egard. ALPS is (or at least can be implemented as) "essentially a static b= yte sequence vended by the application layer protocol". Furthermore, appli= cations already have to vary their payloads dramatically depending on signa= ls from the TLS stack whenever they implement ALPN (by choosing, e.g., HTTP= /1.1 vs HTTP/2). From that standpoint, it seems natural for ALPS handling = to happen at the same or similar I/O points as ALPN handling. > > The distinction here is that a HTTP/2 stack needs to know what the > peer sent for ALPS, which it never did for ALPN. That is, it was > possible to compose TLS and HTTP/2 entirely independently: the TLS > implementation accepted the static byte string from HTTP/2, and if the > ALPN it negotiated matched that string it had successfully negotiated > HTTP/2. I agree that applications needed to know what the ALPN > negotiation was, but HTTP/2 did not. You can observe this in OSS > stacks in the wild, where the HTTP/2 stack never sees the result of > the ALPN negotiation. > > ALPS affects the HTTP/2 wire protocol: it is mandatory that the HTTP/2 > stack behind the TLS implementation be actively told what the peer > presented in ALPS. This was not required with ALPN (H2 could assume it > was being driven based on successful ALPN negotiation of its H2 ALPN > token). While this is not novel for QUIC (see also Transport > Parameters), it is absolutely novel for H2. > > > I am confused by the "fairly unpleasant" part; given that the existing = implementations already can change settings in-band, this sounds like it's = just a matter of making the existing logic conditional. > > The two aren't the same, and the ALPS draft has so far skated around > this problem by not specifying how ALPS would actually work with > HTTP/2. In particular, ALPS must interact with the =C2=A7 3.5 connection > preface in some way. The draft doesn't say how this would work, but > the logical design is that if ALPS is successfully used the connection > preface will be different (it won't bother to include SETTINGS > frames). This cannot help but require tighter coupling between H2 and > TLS, as the H2 stack must now be fed the ALPS data sent by the peer > before it can parse any bytes from that peer. This is simply not a > limitation we have today. David Benjamin kindly followed-up with me off-list to note that I missed an ALPS draft that does express how ALPS maps into HTTP/2. Happily, my guess about how ALPS would map into HTTP/2 matches the document exactly, so the remainder of my criticism still applies. While I'm here though, I'd like to add an additional point regarding draft-vvv-httpbis-alps-00, which is that section 4 should be revised. Specifically, section 4 mandates that any HTTP/2 endpoint that supports ALPS MUST support SETTINGS_HPACK_ENABLE_STATIC_TABLES. The word "support" is unclear here: do I merely have to know what the setting is, or do I have to actually support the functionality? I can only presume the latter, given that ALPS does not support any concept of negotiation. I ask because I think coupling these two features together is unreasonable, and places an unnecessary burden on implementers. There is also no reason to couple them together. This setting should be a separate draft, and should require an appropriate "I support you setting this to 0, but will not be setting it to 0 myself." setting value. This allows peers that actually support this functionality to indicate support for it, without requiring that it be implemented by anyone adopting ALPS. > It is also different from making the existing logic conditional, as > presumably we wouldn't bother with SETTINGS ACKs for ALPS settings. > This is because a) the whole point of ALPS is that those settings are > well-ordered w.r.t. the rest of the protocol, obviating the need for > the ACK at all, and b) it would violate existing stack's assumptions > that SETTINGS ACKs can only be received in response to SETTINGS > frames. This requires a different path for the ALPS settings. > > I want to stress: I don't think ALPS is a bad idea, I think it's a > good one! It clearly brings benefits for protocols that can require > its presence. If we want to mint a new ALPN token for HTTP/2 that also > mandates ALPS support I'm open to that, but frankly without it I don't > see that ALPS helps us much for HTTP/2. > > > > > On Tue, Dec 8, 2020 at 3:48 AM Cory Benfield wrote: > >> > >> On Thu, 3 Dec 2020 at 21:56, David Benjamin wr= ote: > >> > > >> > Hi TLS and HTTP friends, > >> > > >> > At the last HTTPWG interim, there was a question of why one would wa= nt something like ALPS (draft-vvv-tls-alps) for HTTP SETTINGS (draft-vvv-ht= tpbis-alps) over TLS 1.3 half-RTT data. I know we've also had some discussi= on on this topic in the TLSWG as well. At the HTTP meeting, folks suggested= writing up what a half-RTT-based mechanism might look like, so I put toget= her an I-D below. I hope it helps clarify some of our thinking. > >> > > >> > (The I-D is not meant for adoption or publication or anything. I fig= ured an I-D was probably the most familiar format for folks.) > >> > > >> > David > >> > >> Thanks for producing this document David: I think I was one of the > >> folks who pushed for clarification in this area. > >> > >> I think the document does a good job laying out the difficulties with > >> half-RTT data, but it didn't convince me that ALPS is easier for H2. > >> > >> My biggest concerns are around the need to tightly couple the TLS and > >> application layer stacks. ALPN has been reasonably straightforward to > >> handle, being essentially a static byte sequence vended by the > >> application layer protocol. QUIC transport parameters are already > >> harder, but for things like H2 the state machines have to be > >> complicated by the addition of an essentially parallel I/O path. This > >> is because, unlike QUIC, H2 does not (and cannot) spec the requirement > >> for supporting the ALPS extension so the state machines need to > >> tolerate the possibility that they will supply the SETTINGS as > >> ALPS-data but then need to redeliver it in-band, which is fairly > >> unpleasant (doubly so for servers that may want to use multiple TLS > >> stacks, which now have to mitigate timing issues). > >> > >> I think if ALPS were restricted to protocols that could mandate its > >> support then ALPS seems great. For H2 this seems unlikely to be > >> deployed in the long-tail which limits its usefulness, and tbh I think > >> brings more complexity than it's worth. > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls