Re: [TLS] Application-Layer Protocol Settings

David Benjamin <davidben@chromium.org> Tue, 21 July 2020 21:03 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470A13A0A6E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 21 Jul 2020 14:03:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.019
X-Spam-Level:
X-Spam-Status: No, score=-3.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 qEsXfozMhmz6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 21 Jul 2020 14:03:05 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54A073A0A6D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 21 Jul 2020 14:03:05 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jxzMm-0004Pg-9c for ietf-http-wg-dist@listhub.w3.org; Tue, 21 Jul 2020 21:00:00 +0000
Resent-Date: Tue, 21 Jul 2020 21:00:00 +0000
Resent-Message-Id: <E1jxzMm-0004Pg-9c@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <davidben@google.com>) id 1jxzMl-0004Ov-87 for ietf-http-wg@listhub.w3.org; Tue, 21 Jul 2020 20:59:59 +0000
Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <davidben@google.com>) id 1jxzMj-00034Z-7c for ietf-http-wg@w3.org; Tue, 21 Jul 2020 20:59:59 +0000
Received: by mail-pj1-x1029.google.com with SMTP id cv18so1888794pjb.1 for <ietf-http-wg@w3.org>; Tue, 21 Jul 2020 13:59:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M+aMBFQIDIALP6IObYer7Yq/vCX4nsR/hepPJOi5zLI=; b=NGDJIWrpjwxJ6ESYULPuuC4YF6iBqn8heFHOglawcONlk5tou4RhEuSGzfcSNVmMzl 0sj1i2Iy/oXqqoWOKYrWFE3VUTf2r+694x4RAMAoiardXojY6B2bYRsZlpyOXiqADbD2 8SkRwqEDA4W2cQqfR6zVeNnMAF4OFb5GvndQU=
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=M+aMBFQIDIALP6IObYer7Yq/vCX4nsR/hepPJOi5zLI=; b=GqqOdiV/KWKbqwSgtXFHbcWPf9GYgsYg8K71JlLly1e1BCkhrzzGaEDRmQ20Bknnjf dVbPIYHVMcjUfFUcCw0WO08EN9tDF7QGyFfIphv+JK8qoPsbOe0dDShJUUzhjzfSgDL0 Mcmm7qGhS3W1RJy1w6O0+Kw3XDMp7PJpGwKSHw/hkgIxVOJ1Nllx/kFNkuF8EFJdzzKJ uHBcDVDD4otzGXu09pStB1uTXBqXF6Qh6hG6zYV0dyE7EzYTQY73StnygXpOZtk4PsMY Rw4FPMZ/GGVSS9QjpjhjoeuhqWbt4sDHdBEL7N1o0Z4UqyLtTaCL3NKkD3tfl1RiZOMr T43Q==
X-Gm-Message-State: AOAM5309JH8ocfU1byBIFhFz/8vmIjBSp9afw4Bx5tSj/xzILfQJN9EI DF/sxSqHtux5iGFhdGA79PxjpLzT3I8/gHHXQ4wx
X-Google-Smtp-Source: ABdhPJwB6EzNt+5mSYq4Z3c8gJWXRY80r57PqLfwpHPEltySX5Tt8fU6RRB1POX6HXuAwu4Ybd7S7IXhkYum1U72A5Y=
X-Received: by 2002:a17:90a:a78b:: with SMTP id f11mr6328601pjq.42.1595365185595; Tue, 21 Jul 2020 13:59:45 -0700 (PDT)
MIME-Version: 1.0
References: <CAAZdMaf2dKab0dJU8MLZc9JzEcVSvf8s9kgeZFo3tmsRtx2sNQ@mail.gmail.com> <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com> <CAAZdMacsDdcZCcS1yLSQwO3rbhnh8AVkgZHrt+A+KDKKaYWO7g@mail.gmail.com> <d9201e80-19b9-4854-9655-10935414143c@www.fastmail.com> <CALGR9obNTmDLKHrYMncKb7-aMSOnvS8H=Vu0Wjg1PgEk+U993A@mail.gmail.com> <CAAZdMaeRuytb=hDSXOjxZiMBct5kzY4sZ41bRZLmChEPvFLJjA@mail.gmail.com> <CAF8qwaByEJ4g7gqfg4q1EC=6zC7H2gqxZAhWTWtt+K7Fv-nWUw@mail.gmail.com> <CALGR9oaiygX0t_1R3LUEbUVaj1Gijt_fjgVQ46WU=xmF2c1eVA@mail.gmail.com> <CAF8qwaDUOMcBWS6P85eq8_dr--xKhuOSVrvVuqKz09apDmo0Mg@mail.gmail.com> <CALGR9oaNt-xfSfRUJnLXJ6JUgnB62CvMWB5F0qswpRHwA1wn1g@mail.gmail.com> <CAF8qwaBs0YtYFDfYWQUtZSz3z+TJJhMfbkf7ghn=umP_Nwhj9g@mail.gmail.com> <CAAZdMae-jZVfv98jC3ru51uk6H6TZuaQ+P=PJW-BZ9uEKVbQCA@mail.gmail.com>
In-Reply-To: <CAAZdMae-jZVfv98jC3ru51uk6H6TZuaQ+P=PJW-BZ9uEKVbQCA@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Tue, 21 Jul 2020 16:59:29 -0400
Message-ID: <CAF8qwaBf75VRqs9Rfs=MXdp_e569Spmi+HnXjgu_G6+0E-j2pQ@mail.gmail.com>
To: Victor Vasiliev <vasilvv@google.com>
Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, "tls@ietf.org" <tls@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000002d00cf05aaf9e79c"
Received-SPF: pass client-ip=2607:f8b0:4864:20::1029; envelope-from=davidben@google.com; helo=mail-pj1-x1029.google.com
X-W3C-Hub-Spam-Status: No, score=-11.5
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1jxzMj-00034Z-7c fd359f64b51d9ccae8502a74166a36e3
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [TLS] Application-Layer Protocol Settings
Archived-At: <https://www.w3.org/mid/CAF8qwaBf75VRqs9Rfs=MXdp_e569Spmi+HnXjgu_G6+0E-j2pQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37906
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: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

I guess you could have protocol-specific numbers and protocol-independent
syntax? Or you could allocate numbers in yet another number space for all
the existing settings. The latter seems like a lot of fuss, and the former
is kinda weird. At that point you may as well get a protocol-specific blob
(as in the draft) so the protocol library can reuse their preferred parsing
routines.

On Tue, Jul 21, 2020 at 4:22 PM Victor Vasiliev <vasilvv@google.com> wrote:

> 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 <davidben@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 Benjamin <davidben@chromium.org>
>>> wrote:
>>>
>>>> On Mon, Jul 20, 2020 at 5:00 PM Lucas Pardue <
>>>> lucaspardue..24.7@gmail.com <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
>>
>