Re: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt

Ryan Sleevi <ryan-ietf@sleevi.com> Sun, 15 August 2021 08:13 UTC

Return-Path: <ryan.sleevi@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822BD3A0CEF for <quic@ietfa.amsl.com>; Sun, 15 Aug 2021 01:13:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 K8tCZ80nfYHQ for <quic@ietfa.amsl.com>; Sun, 15 Aug 2021 01:13:12 -0700 (PDT)
Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) (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 E8FD33A0CEE for <quic@ietf.org>; Sun, 15 Aug 2021 01:13:12 -0700 (PDT)
Received: by mail-pl1-f176.google.com with SMTP id a5so17280528plh.5 for <quic@ietf.org>; Sun, 15 Aug 2021 01:13:12 -0700 (PDT)
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=MhEP2YJaAQp37cy5470DtQK+/WbKrNZAOI8PYpZaOEc=; b=XWqLHSsg3R8YkTifl54D0XyzZRvboy6rzL+Bzu/4zSfbhJiVMXPrbkRef72SD20zwB S4UoB4q2c2q80opS2J1bK2CcKZ6DPG4Ky8qkWGPuBQzQCX6vXCYlWIJyZn6r+5umVKH4 qKJouLilL9pIogx4qR2a0pFhY4zAMLoWyrJzt4OPCAIs4nljpVMOZjc0cWmxP05hCeQt woaOuN/JbtopjRmXPK6TToswPy6RMwr1kQHZJYuHDbQJfE8M1AUviwzogC5kFdRz3IxG A1hKiGNnxHQgFk13nqekdq5HJybDQc/rpVtCLRrNBMK2aXWaxSum0Op0pKZ3DcET+WNM nxGQ==
X-Gm-Message-State: AOAM530PR8WB+Yfs3zVCZNOLT7qYoyyrnWujJm78W6iUnoSPaeB60Hyt gvAphRbccjQWdttpsZ4mo9LGbC5difc=
X-Google-Smtp-Source: ABdhPJzl+Ij9CzKdDRTSu9WJLhEh713G6ueS67ypBu4b+IP/evlvvu2HyxN8bHJqEJuY0W+JirH3sw==
X-Received: by 2002:a63:5659:: with SMTP id g25mr10226626pgm.354.1629015191970; Sun, 15 Aug 2021 01:13:11 -0700 (PDT)
Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com. [209.85.214.181]) by smtp.gmail.com with ESMTPSA id 20sm9743612pgg.36.2021.08.15.01.13.11 for <quic@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Aug 2021 01:13:11 -0700 (PDT)
Received: by mail-pl1-f181.google.com with SMTP id a20so17341847plm.0 for <quic@ietf.org>; Sun, 15 Aug 2021 01:13:11 -0700 (PDT)
X-Received: by 2002:a17:90a:d3d0:: with SMTP id d16mr11171871pjw.103.1629015191628; Sun, 15 Aug 2021 01:13:11 -0700 (PDT)
MIME-Version: 1.0
References: <162883401993.25302.7275724432785172464@ietfa.amsl.com> <CANatvzxWrg+rciDpOZqsnDWq_oW_cr-Do2SjUzGgPy_vyAUs=Q@mail.gmail.com> <CAC7UV9aVnrUfvLuMB6dFSqiVzyr5PNF_xc+nRiZve35R3xqyrw@mail.gmail.com> <CANatvzx_O_38nU3wyD6UCtFRfBSarT4=NO45yOQMbSOe0oCK=g@mail.gmail.com>
In-Reply-To: <CANatvzx_O_38nU3wyD6UCtFRfBSarT4=NO45yOQMbSOe0oCK=g@mail.gmail.com>
From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Sat, 14 Aug 2021 22:13:01 -1000
X-Gmail-Original-Message-ID: <CAErg=HEJ_r2TgEf643Y49DKdawyJUZeypS0e2oTVXsBihSHpTA@mail.gmail.com>
Message-ID: <CAErg=HEJ_r2TgEf643Y49DKdawyJUZeypS0e2oTVXsBihSHpTA@mail.gmail.com>
Subject: Re: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, IETF QUIC WG <quic@ietf.org>, Jana Iyengar <jri.ietf@gmail.com>, Robin MARX <robin.marx@uhasselt.be>
Content-Type: multipart/alternative; boundary="000000000000d4b1c405c994a7f0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/qunSF9ClnM9n_cF7UNXVHabqibY>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Aug 2021 08:13:16 -0000

On Sat, Aug 14, 2021 at 8:24 PM Kazuho Oku <kazuhooku@gmail.com> wrote:

>
>
>> 3) Relatedly, your POC seems to assume the browser will have just a
>> single connection and a trace request in a second tab will auto map to that
>> connection.
>>
>     That works fine for the POC, but for a real deployment that lets
>> end-users fetch traces, you'd need built-in browser/client support to
>> select a specific connection / fetch traces for all connections to a given
>> origin.
>>      Not a big problem ofc, and things like Chrome's netlog export
>> already do this, but still a practical hurdle.
>>
>
> Right. I would hope that it would be possible to implement this as a
> browser extension at least (with the assumption being that requests from a
> browser extension would be coalesced with other requests going to the same
> authority).
>

Unfortunately, browsers do not guarantee this property, and past efforts in
the IETF to standardize features that assume this property (e.g. Token
Binding) or in other SDOs (e.g. ETSI’s unfortunate design with regards to
QWACs) end up not working in practice.

This is especially true as browsers look to segment connections even
further, in relation to privacy properties unique to browser environments
(e.g. CORS credentialless, as further expanded by COEP, or the fetch()
specifications Network Partition Keys, or security isolation primitives to
restrict extension access).

I don’t have much stake in this, other than flagging that any design that
makes assumptions about connection properties to bits on screen are,
generally, flawed assumptions. That’s not to preclude the possibility of
direct browser integrations, should it prove useful and of demonstrable
value to merit such implementation, although past efforts have failed to
achieve that value relative to the complexities of such coupling.