From nobody Mon Feb 1 05:46:16 2021 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 2E4A23A1182 for ; Mon, 1 Feb 2021 05:46:15 -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 GulvdLcCnbZo for ; Mon, 1 Feb 2021 05:46:13 -0800 (PST) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 284F73A1181 for ; Mon, 1 Feb 2021 05:46:13 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id h7so22808131lfc.6 for ; Mon, 01 Feb 2021 05:46:12 -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=iolRfmKh3vB8OL/foEbLiXAg4N4YRDTKocklAkod9oo=; b=t/B52849VSXVDi6ocq5JSw8L1tokI6jYzMm+y8cD1cF5tfVzXZJpr/T3OD3NuniAeI YNtH7ZnG2hoZVbKtt0Pn+N6hvcLZhO/7v4Mlys0n3POVZkyiZxti+RJlh/ngjlzzplt9 WRP/U/HmK1uaARm1akB23C1PA/0WCJNYj5/YRQzOqKFFm+PjNNRYHIc6uOQ9tE7YozRa YpN8pyJgWfk28Fdh2gMCQ1QavhTGtkNY/k66g/sGvorRCtsXJROUs8VFmfbxyqfS863Z +KoRoihdcpzEuQULQcdOONfI/bfFP4O4WBqsaemZ5Qb4WewXKeQMaKXVcRyXPYrASl4B 5Jbw== 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=iolRfmKh3vB8OL/foEbLiXAg4N4YRDTKocklAkod9oo=; b=Bt9WyiLrrVcabgnWAEweujjjglm64bRyUsUiJCGi+Z3M2PSq/8ufs6iHw7Vwb8D5FL 6N6K73APYYcGSuninQEU6WMxL/4WGhot4nGeKb7D5cK1wTFgFiPZ4rxf0JiKwzZy9X6M 5ghngcI1iTDElsHzSu48+eNLoZsxaMSsW/SpUvrr/g5m+noYBll5hvyruQIntcNNElC8 jayJkmceVjc5o6IpMEbFmSxYJ+B5vSgu8LK9RdElvYi1A8DWDh/yBH3xIGrvBU7NLI+T qPkmH+LuBe6g71kcv8h66/a0TrqjslHBWam733Rz7aEnRBjrcxy2kpArUWMeDN8IZ5ud 1CIA== X-Gm-Message-State: AOAM533HNT6E46kdXOIvyq59GUQRX+zlshrG0QfafNix2gvuTIKEGFMF wg9BWFftRh8P3Dj5m1ZWFD0SlJhB1Bcyh6yJyb5G7w== X-Google-Smtp-Source: ABdhPJxAJ7w1qx3bzyJ9IU1ux7bFi43XCvGB9Lcvi12vaUCjOGGcGdNi2dQqqZFi3f3Weap2Ftd5Y93gJp1GALQ8tyQ= X-Received: by 2002:a19:f707:: with SMTP id z7mr8801854lfe.548.1612187171250; Mon, 01 Feb 2021 05:46:11 -0800 (PST) MIME-Version: 1.0 References: <160703055132.9234.3055845983488231389@ietfa.amsl.com> In-Reply-To: From: Cory Benfield Date: Mon, 1 Feb 2021 13:46:00 +0000 Message-ID: To: David Benjamin Cc: Victor Vasiliev , "" , 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: Mon, 01 Feb 2021 13:46:15 -0000 On Fri, 29 Jan 2021 at 23:38, David Benjamin wrote: > > Hi all, > > > Thanks all for the feedback. I=E2=80=99ve tried to address it below, but = there's a lot of text, so please let me know if I=E2=80=99ve missed or misu= nderstood any of your points. > > > Cory commented on SETTINGS_[HQ]PACK_ENABLE_STATIC_TABLES in draft-vvv-htt= pbis-alps-00. I agree that is odd. We=E2=80=99ve uploaded a draft-01 that d= rops it. > > > Cory also wrote: > > > 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. > > > To clarify, are you unconvinced that ALPS is easier than leaving H2 alone= , or that ALPS is easier than solving this problem with half-RTT? The docum= ent=E2=80=99s aim is the latter. Your comment in Martin=E2=80=99s thread re= ads to me like you agree with this. Am I interpreting that correctly? (I th= ink draft-thomson-httpbis-h2-0rtt roughly corresponds to Section 2.3 of my = document. Something like it would be necessary, but not sufficient, to solv= e this with half-RTT.) > > > As to leaving H2 alone, doing nothing is indeed generally easier than doi= ng something. But this is perhaps not a useful criteria. :-) The question i= s what=E2=80=99s the benefit of solving the problem. My interest is in the = privacy benefits of rethinking content negotiation. Victor has use cases ar= ound WebTransport. The document cites some other uses. I am unconvinced that ALPS is easier than leaving H2 alone _and_ that I've not been sold on the criticality of adding content negotiation of this form. You say you're interested in the privacy benefits, but the draft doesn't state what those are expected to be, or what they're being compared to. I assume they're being compared to 0.5RTT data. If that's true, then sure, I can see the privacy benefits. However, that's not the status quo, and so not necessarily a meaningful comparison point. The document notes a single rationale: > One of the properties of the > mechanism as defined by both of those protocols is that the parties > start out without having access to the entirety of the peer's > settings. This means that they have to initially operate using the > default settings, and after receiving the SETTINGS frame, they have > to find a way to transition from the default to the exchanged > settings. I agree that this statement is an accurate representation of the state of things today. I also agree that having access to the settings before application traffic is negotiated will enable some use-cases that are otherwise tricky. But this is still not a concrete problem statement, merely a statement of hypothetical utility. > > My biggest concerns are around the need to tightly couple the TLS and > > > application layer stacks. > > > I agree this adds a non-I/O TLS interaction, but adding interactions isn= =E2=80=99t new. Many HTTP mechanisms touch TLS: > > RFC8473 uses TLS exporters. > RFC5929 specifies various TLS channel bindings interfaces for authenticat= ion protocols. > RFC8470 integrates with the 0-RTT/1-RTT transition point. > ALPN itself uses TLS to select variations on HTTP. > Section 9.2.2 of RFC7540 specifies cipher suites for HTTP/2. > HTTP/2 cross-name pooling and HTTP=E2=80=99s general notion of authority = are tied to the TLS certificate. > Applications using client certificates care about the relation between TL= S-level authentication and HTTP messages. The web even has a notion of =E2= =80=9Cuncredentialed=E2=80=9D HTTP fetches which shouldn=E2=80=99t send cli= ent certificates. > Secondary certificates use TLS exported authenticators. > > Systems and thus their problems span components. The question is how best= to split a solution across those components. The aim with ALPS is to minim= ize coupling while still getting settings for the first client write. We ca= n build something piecemeal with half-RTT, ticket state, and early data cal= lbacks. Or we can abstract a notion of =E2=80=9Cprotocol settings=E2=80=9D,= configured and surfaced at well-defined points. I prefer the latter. Systems do span components, but reducing coupling between those systems is good. I agree that glomming things together out of an arbitrary collection of poorly supported protocol components is not a better solution than having a single extension point. I am pressing back on the idea that this problem requires coupling these systems at all. Well-designed, simple, extensible coupling is better than poorly designed coupling, but worse than no coupling at all. > As to the complexity, I think you may be overestimating it. It sounds lik= e your model has three components: TLS, HTTP/2, and some ALPN dispatcher. A= nd your concern is complexity in HTTP/2. Is that right? ALPS should slot ne= xt to ALPN processing at the same points. For example: > > The dispatcher already must know which ALPN protocols are supported and h= ow to instantiate them. > Extend it so protocols can optionally be ALPS-aware. An ALPS-aware protoc= ol has a settings parameter in the instantiation function. It also configur= es settings to send. This all happens at the same time as existing ALPN set= up. > The dispatcher runs the TLS handshake and gets an ALPN protocol as before= , plus now an ALPS value. > The dispatcher instantiates the protocol as before, but if ALPS was negot= iated, also passes a byte string to the ALPS-aware handler. Note the extens= ion ensures this can only happen if the protocol was configured as ALPS-awa= re above. > > The protocol acts accordingly. If ALPS was negotiated, HTTP/2 would apply= the received settings to the initial peer state. It also knows the initial= local state is different and can skip sending some values. This is added l= ogic to HTTP/2, but I think it=E2=80=99s fairly minimal. (And we can certai= nly figure out the exact details that would work best.) It even has precede= nt in the HTTP Upgrade path for =E2=80=9Chttp=E2=80=9D URLs, so it's not ev= en really new. Also note that all this happens before any of the usual appl= ication I/O. (I wasn't sure what you meant by "timing issues". Could you el= aborate? I read it to mean where the integration points were, so hopefully = the example above helps clarify. Also note that all of the logic above is s= ynchronous. We don't need new points in state machines to wait for data.) The above is, in various subtle ways, not going to match what I have to deal with. That's not the end of the world though: we shouldn't critique this general proposal based on one specific implementation. The timing issues here are around your "note that this happens before any of the usual application I/O". This is not a trivial invariant to enforce, and many stacks haven't had to bother. Highly integrated stacks such as those found in major user agents and standard HTTP servers tend to have this ironed out, but frameworks that support arbitrary configuration have extra work to do here. Nonetheless, I agree that the complexity here is not unmanageable.