From nobody Mon Feb 1 05:50:10 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 E99CC3A1189 for ; Mon, 1 Feb 2021 05:50:08 -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 hBYI55tKmbu8 for ; Mon, 1 Feb 2021 05:50:07 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 C223D3A1188 for ; Mon, 1 Feb 2021 05:50:06 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id s18so19650106ljg.7 for ; Mon, 01 Feb 2021 05:50:06 -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=ctfwLefZO8YjupgYG8Ljnvelp7L1/ZtegDZmrxdevNg=; b=tzIl9Tr5Ky7FApVpILdMP9oAehpAf5JW8oJsO7ptvqeER/XEtd9OtYnJeT2DUk3Lyr XUDP5pKcmo5YBjy56TOfPs2lALjFG8DL0slrmHbqIAMxsBeevXoGlHE8wnxI3/wSXZwu aF3HKDWUYxZA+Bt21tOtnGZ+L8yO1Ddxb3EaEzvDnxvvf1/hRY+Y6e8KvIIWlOYFoShd wAw3CYFvncOqUadxCwZ2zw680LoTe2/w9wMeWqMewYT1UQhfwv5BAp8d0+/ly1DSUQcl /Fkq2IbxvDtM2EnSS8GCYZi7JNwTFifSdzk8yG4GaOMxvNrZdRwo1/ul/45TDpwdTIVx DHXQ== 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=ctfwLefZO8YjupgYG8Ljnvelp7L1/ZtegDZmrxdevNg=; b=ICmnKPdObbgt23f0ViElyKU1ozuGBUP41TYTG1IDjRP7By0TmdhVbmSSCvMD7cQehB y00/shcB0eGPg5Sb0oXLFigChVO3C4isZY5WdsiN1lVOcbQl7IMH3sC8PL7M+yrbU9N2 pXCaoHDZDfCh3NLBUtSioGQnOVlOq2tear+G8r4whJAG1MkhJG6hlBRRsB64ZRJrr2Ba jlOptSwztQmeVg8d+bSh0gIRZxst7nLVfKcfQtL853Qj3ERhWzHq53o0ev60I01hnenJ jWY1AviSRyqo4llvwzuoD12HFjtbGCvohqtAX3Rdq7I+74UNo8jaq46y9ow67Gd0gPF7 6Y7A== X-Gm-Message-State: AOAM531BQJvYUyr3FIl8KiO//kM68/iPdM1T3Pu8SZ8yCYq5aBmtsRmw 1Z8pgA3UUqfOHj6ZggEd6bfklTpRD0U+i3RbQ8uwwA== X-Google-Smtp-Source: ABdhPJwQsZxUKGod5XmdacxMAn3b83LfmNkCXZRFaTF6JJqUbKb3i1R3wgZGDi3ZebgmnubL4wli7FK6vdnQpHEvJps= X-Received: by 2002:a2e:1519:: with SMTP id s25mr10097596ljd.495.1612187404919; Mon, 01 Feb 2021 05:50:04 -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:49:53 +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:50:09 -0000 Oh, and I should say this out loud: my attitude to ALPS has softened in the past two months or so. I definitely don't want my comments to be perceived as being in opposition to the adoption of new work by this WG: I just want to flesh out exactly what problems we're trying to solve, so that we can accurately assess whether ALPS is the right solution for them. ALPS is a good solution to some real problems. I want to make sure I understand what problems it's solving in H2, so I can try to judge whether I think it's a good solution for _those_ problems. On Mon, 1 Feb 2021 at 13:46, Cory Benfield wrote: > > On Fri, 29 Jan 2021 at 23:38, David Benjamin wrot= e: > > > > Hi all, > > > > > > Thanks all for the feedback. I=E2=80=99ve tried to address it below, bu= t there's a lot of text, so please let me know if I=E2=80=99ve missed or mi= sunderstood any of your points. > > > > > > Cory commented on SETTINGS_[HQ]PACK_ENABLE_STATIC_TABLES in draft-vvv-h= ttpbis-alps-00. I agree that is odd. We=E2=80=99ve uploaded a draft-01 that= drops 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 alo= ne, or that ALPS is easier than solving this problem with half-RTT? The doc= ument=E2=80=99s aim is the latter. Your comment in Martin=E2=80=99s thread = reads to me like you agree with this. Am I interpreting that correctly? (I = think draft-thomson-httpbis-h2-0rtt roughly corresponds to Section 2.3 of m= y document. Something like it would be necessary, but not sufficient, to so= lve this with half-RTT.) > > > > > > As to leaving H2 alone, doing nothing is indeed generally easier than d= oing something. But this is perhaps not a useful criteria. :-) The question= is what=E2=80=99s the benefit of solving the problem. My interest is in th= e privacy benefits of rethinking content negotiation. Victor has use cases = around 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 is= n=E2=80=99t new. Many HTTP mechanisms touch TLS: > > > > RFC8473 uses TLS exporters. > > RFC5929 specifies various TLS channel bindings interfaces for authentic= ation 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 authorit= y are tied to the TLS certificate. > > Applications using client certificates care about the relation between = TLS-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 = client certificates. > > Secondary certificates use TLS exported authenticators. > > > > Systems and thus their problems span components. The question is how be= st to split a solution across those components. The aim with ALPS is to min= imize coupling while still getting settings for the first client write. We = can build something piecemeal with half-RTT, ticket state, and early data c= allbacks. 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 l= ike your model has three components: TLS, HTTP/2, and some ALPN dispatcher.= And your concern is complexity in HTTP/2. Is that right? ALPS should slot = next to ALPN processing at the same points. For example: > > > > The dispatcher already must know which ALPN protocols are supported and= how to instantiate them. > > Extend it so protocols can optionally be ALPS-aware. An ALPS-aware prot= ocol has a settings parameter in the instantiation function. It also config= ures settings to send. This all happens at the same time as existing ALPN s= etup. > > The dispatcher runs the TLS handshake and gets an ALPN protocol as befo= re, plus now an ALPS value. > > The dispatcher instantiates the protocol as before, but if ALPS was neg= otiated, also passes a byte string to the ALPS-aware handler. Note the exte= nsion ensures this can only happen if the protocol was configured as ALPS-a= ware above. > > > > The protocol acts accordingly. If ALPS was negotiated, HTTP/2 would app= ly the received settings to the initial peer state. It also knows the initi= al local state is different and can skip sending some values. This is added= logic to HTTP/2, but I think it=E2=80=99s fairly minimal. (And we can cert= ainly figure out the exact details that would work best.) It even has prece= dent in the HTTP Upgrade path for =E2=80=9Chttp=E2=80=9D URLs, so it's not = even really new. Also note that all this happens before any of the usual ap= plication I/O. (I wasn't sure what you meant by "timing issues". Could you = elaborate? I read it to mean where the integration points were, so hopefull= y the example above helps clarify. Also note that all of the logic above is= synchronous. 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.