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 97AAF3A095F for ; Tue, 21 Jul 2020 13:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 LB7f_mWku52S for ; Tue, 21 Jul 2020 13:22:44 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 6AD013A0965 for ; Tue, 21 Jul 2020 13:22:44 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id x9so82594ljc.5 for ; Tue, 21 Jul 2020 13:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fz4avZOD/H4YZt9nH5xT7BsQX2Y0qIggwkhB+HfeGDA=; b=NWk/U5d1RpUqyskAjxJQhwfmXwNvehV9PMcGDhnI+px09XX9VO2DhzNA9rF021fybT Vt5dW6hfXMKvAQ+84V7UhaumwjOdxFeBSTOMwOp6aoWiTiRPwXL982ORe6cms8V+lzIU dyGJqXnByQ4V8qGYvoCJmqEYlG/tZZBTDZprTuifIgQTh5V2mgIUsHRcBKzarWLYUVhR X53EySwkQAZU9hGUd+ZYhBRAp0XNj9T1rytwD9+/8LK5i3mK6IjE1p62lczRPc1OT0Qp Nwbbl73URv+HzuTE+K+3ZCcgiy+KLRlArDW+bExfSBJQS1S4O0uDOMDtAqq/H5B+re4l UB4g== 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; bh=Fz4avZOD/H4YZt9nH5xT7BsQX2Y0qIggwkhB+HfeGDA=; b=hyUSOF/f2MI2gD8AKoNoPYzaBK2aAjUOyF8qP1Y+pCt590M3HMop3AOLKVpFgf19Am 7kxo16fe65BefC9xIlTnkmxIQAQ6JAe1MZw8DydFJmwfQOmU544WZbU+e2bm5wXf2K+9 uYHc79dTQer6JmaC0YY8BN7tF4SWFqXq2nTflXCNcIkcw9wo6TOV0j/rUA/3d0o16+MP Ju4iYMiPVq+zi9cQNjA+UJ2MWK6DyNggUuOl6WjVByAF+AV7B7K3MYtTznLeJwZavL75 Ek4PzRjDfG8tn+mzwk4rnukXf2B6Fgl/vz1L9Meen8HuJ4dq8xbV2NKZUnFPoCFC4q2H wacg== X-Gm-Message-State: AOAM531ODznU0j82OwOLSckbhAhL4lEk7sozyeuG3FN+8OosjtfVAGNZ V7eFHUz1qBpEmuZmKsikP4H+7z+0GoU0pZ7oMDbYlg== X-Google-Smtp-Source: ABdhPJwvjfV/57Stz/lmQ27lviv1Zr4EmqOMK4j0HWghhlMKvu0xc0j/xCHO/GgUSOBrRc9TosF8bTaJb13AI2Rc1Uk= X-Received: by 2002:a2e:9b87:: with SMTP id z7mr14524797lji.80.1595362962121; Tue, 21 Jul 2020 13:22:42 -0700 (PDT) MIME-Version: 1.0 References: <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com> In-Reply-To: From: Victor Vasiliev Date: Tue, 21 Jul 2020 16:22:30 -0400 Message-ID: To: David Benjamin Cc: Lucas Pardue , "tls@ietf.org" , HTTP Working Group Content-Type: multipart/alternative; boundary="000000000000a5b76c05aaf96275" Archived-At: Subject: Re: [TLS] Application-Layer Protocol Settings 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: Tue, 21 Jul 2020 20:22:47 -0000 --000000000000a5b76c05aaf96275 Content-Type: text/plain; charset="UTF-8" How would this work with regular SETTINGS? HTTP/2 and HTTP/3 have disjoint setting number spaces, and it's unclear to me whether there's any significant overlap between those. On Tue, Jul 21, 2020 at 11:49 AM David Benjamin wrote: > On Tue, Jul 21, 2020 at 8:22 AM Lucas Pardue > wrote: > >> >> On Mon, Jul 20, 2020 at 10:42 PM David Benjamin >> wrote: >> >>> On Mon, Jul 20, 2020 at 5:00 PM Lucas Pardue < >>> lucaspardue..24.7@gmail.com > wrote: >>> >>>> >>>> That makes sense but I guess I don't see the point in defining a new >>>> thing that contains frames that are never sent on streams. That is, if >>>> these are connection settings, just send the payload. Unframed extended >>>> settings might get you there, if you can find a way to encapsulate >>>> conventional settings inside them, then all the better. >>>> >>> >>> Could you elaborate on this a bit? I'm probably just failing to parse, >>> but I'm not sure which alternative you're suggesting here. (Ah, the wonders >>> of email.) >>> >>> David >>> >> >> I was trying to accommodate HTTP/2 and HTTP/3 in one breath, which is why >> my intent was probably unclear. Basically, if ALPS relies on frames for >> per-protocol settings then it has to accommodate the differences in frame >> format between HTTP/2 and HTTP/3. In the examples from the ALPS and Client >> Reliability proposals, the H2 frame needs to populate the frame header and >> it pick stream 0, which doesn't exist until the connection is actually >> made, so seems a bit kludgy. In H3, frames don't have the stream ID so you >> avoid the problem above. >> >> So my thought was to basically do away with the notion of >> protocol-specific frames in ALPS, and instead define the a common payload >> format that perhaps looks something like bishop-extended-settings [1], a >> series of Type-Length-Value (but without any frame headers). This would >> allow you to encode the old and new settings in a single format, rather >> than needing to delineate things via frames. >> >> [1] - >> https://tools.ietf.org/html/draft-bishop-httpbis-extended-settings-01#section-3.1.1 >> > > Ah, gotcha. The thinking was the settings were ALPN-specific anyway, so we > may as well define them however is more idiomatic for the protocol. This > means we automatically can make existing H2 and H3 settings more reliable. > Settings values can also be updated over the course of the connection, so > using frames keeps continuity there. But, yeah, a separate key/value syntax > would work too. > > (A small correction, the current Client Hint Reliability proposal allows > ACCEPT_CH to be sent in application data too. Maybe the frontend realizes > the origin's ACCEPT_CH preferences have changed and wants to notify > existing connections. Though I don't consider this feature important. I > doubt most folks, if anyone, will bother with this. Mostly that's how a > SETTINGS or EXTENDED_SETTINGS value already would have worked, so I figured > the semantics ought to be compatible in case EXTENDED_SETTINGS is revived.) > > David > --000000000000a5b76c05aaf96275 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
How would this work with regular SETTINGS?=C2=A0 HTTP/2 an= d HTTP/3 have disjoint setting number spaces, and it's unclear to me wh= ether there's any significant overlap between those.

On Tue, Jul 21, 202= 0 at 11:49 AM David Benjamin <d= avidben@chromium.org> wrote:
On Tue, Jul 21, 2020 = at 8:22 AM Lucas Pardue <lucaspardue.24.7@gmail.com> wrote:

On Mon, Jul 20, 2020 at 10:42 PM David Benjam= in <davidben@= chromium.org> wrote:
On Mon, Jul 20, 2020 at 5:00 = PM Lucas Pardue <lucaspardue..24.7@gmail.com> wrote:

That makes sense but I guess I don't see the point= in defining a new thing that contains frames that are never sent on stream= s. That is, if these are connection settings, just send the payload. Unfram= ed extended settings might get you there, if you can find a way to encapsul= ate conventional settings inside them, then all the better.

Could you elaborate on this a bit? I'm pro= bably just failing to parse, but I'm not sure which alternative you'= ;re suggesting here. (Ah, the wonders of email.)

D= avid

I was trying to acco= mmodate HTTP/2 and HTTP/3 in one breath, which is why my intent was probabl= y unclear. Basically, if ALPS relies on frames for per-protocol settings th= en it has to accommodate the differences in frame format between HTTP/2 and= HTTP/3. In the examples from the ALPS and Client Reliability proposals, th= e H2 frame needs to populate the frame header and it pick stream 0, which d= oesn't exist until the connection is actually made, so seems a bit klud= gy. In H3, frames don't have the stream ID so you avoid the problem abo= ve.

So my thought was to basically do away wi= th the notion of protocol-specific frames in ALPS, and instead define the a= common payload format that perhaps looks something like bishop-extended-se= ttings [1], a series of Type-Length-Value (but without any frame headers). = This would allow you to encode the old and new settings in a single format,= rather than needing to delineate things via frames.

[1] - https://tools.ietf.org/html/draft-bishop-ht= tpbis-extended-settings-01#section-3.1.1
=

Ah, gotcha. The thinking was the settings were ALPN-spe= cific anyway, so we may as well define them however is more idiomatic for t= he protocol. This means we automatically can make existing H2 and H3 settin= gs more reliable. Settings values can also be updated over the course of th= e connection, so using frames keeps continuity there. But, yeah, a separate= key/value syntax would work too.

(A small correct= ion, the current Client Hint Reliability proposal allows ACCEPT_CH to be se= nt in application data too. Maybe the frontend realizes the origin's AC= CEPT_CH preferences have changed and wants to notify existing connections. = Though I don't consider this feature important. I doubt most folks, if = anyone, will bother with this. Mostly that's how a SETTINGS or EXTENDED= _SETTINGS value already would have worked, so I figured the semantics ought= to be compatible in case EXTENDED_SETTINGS is revived.)

David
--000000000000a5b76c05aaf96275--