Re: Genart last call review of draft-ietf-httpbis-client-hints-13

Yoav Weiss <yoav@yoav.ws> Wed, 06 May 2020 08:07 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 C365B3A07EA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 6 May 2020 01:07:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.65
X-Spam-Level:
X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yoav-ws.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 bueuAzo6jp6E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 6 May 2020 01:07:52 -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 2735B3A07E9 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 6 May 2020 01:07:51 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jWF2c-0003aN-UE for ietf-http-wg-dist@listhub.w3.org; Wed, 06 May 2020 08:05:08 +0000
Resent-Date: Wed, 06 May 2020 08:04:30 +0000
Resent-Message-Id: <E1jWF2c-0003aN-UE@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 <yoav@yoav.ws>) id 1jWF2R-0003Y0-B9 for ietf-http-wg@listhub.w3.org; Wed, 06 May 2020 08:04:29 +0000
Received: from mail-lj1-x232.google.com ([2a00:1450:4864:20::232]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <yoav@yoav.ws>) id 1jWF2N-00026E-Va for ietf-http-wg@w3.org; Wed, 06 May 2020 08:04:18 +0000
Received: by mail-lj1-x232.google.com with SMTP id h4so1307823ljg.12 for <ietf-http-wg@w3.org>; Wed, 06 May 2020 01:04:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yoav-ws.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zGbdRqQ/GDY33nnFKNSUYQ50SmEI99j9aXj14sX4VLM=; b=qGRlo+fiUE/5GRs+Ujh9UzCAJ/6fVLrzVN2e++luC5ffLDuTLHoJ9TBWU4H3FmUMaY IgjfLI+1zOSQsRAXCeKFRwuSX1HAavdjTOPyoRCjK3rPJluXJsMXB3OQNWdILk9rZp4n LeT7n4DzxmomuicI6Lyx7FaScBaCxHLvUkUdTAIo0BvExSUz/9OcOcCDo4/U5SNG8ZAL Oq3SzN0xxBy7vF54OKPdT+vvvM6Vf3MiO587819fI1J+0GQj9w5V9ZbLCo8TRSgjfQ2G 8SmxzKTz04oU9lG8xKTjzeMwKvQEtFeQ3PIPEeL1YaOvXFt7xOXvApLsGU/JeqKNfUIG 9l+A==
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=zGbdRqQ/GDY33nnFKNSUYQ50SmEI99j9aXj14sX4VLM=; b=EQ+PKzB7l4tj0f0AXHNfERFXYgdqk8q45cRp2QszyPZJaQZelDZTT7dklaWAn/7rwv qsZD1MySAikbk9N35UDBO7nwY13FRB+RSf0xin5tTeGXIHkOcsm+uVYRvU3bBRaC1d3F GvWd8ttQyK54XDAAGTV+tv4sdSA2y5MGpxiEStD6Baw2M2TjBGgSxmoCgoUkq+X4rhJG uYOjEMPUGiDZo4FS68XNWP3zjo27e68eADnkE+hVlD0U7w8bV0XYt2q//5ABhbtwE4u9 PBaNe/VpR/Dvf0aqXs9Ow7LAqXlzpA8yIfH+Y8FwjgWpNIxIzmao5yFz4jsnnsyAHtbM NoDg==
X-Gm-Message-State: AGi0PubgB//fxxGnf352qBMtK7e1iwI3eBh5VA+C/LBlTG7lyRaQ22GV Ny4KwImNekRZwMxZR6XOwu5OwfFGXvAEsAztCsAtug==
X-Google-Smtp-Source: APiQypI/HlaS8tD87k4+FeFESTu5ARAEXD+S4W+00aXTS6I4C5Q7UVLq0K6YGiBgt5+l+C/NPZtna8Hwjl6JMmq5/OY=
X-Received: by 2002:a2e:8108:: with SMTP id d8mr4007533ljg.184.1588752244088; Wed, 06 May 2020 01:04:04 -0700 (PDT)
MIME-Version: 1.0
References: <158837305177.24719.21462684096579298@ietfa.amsl.com> <CACj=BEhNqVRxQagFmJ4sbXrn=YOWAYPBqODw_rL7MZbUDjNq5w@mail.gmail.com> <A2613BDC-7577-4BED-8AB5-4799973A1586@ericsson.com>
In-Reply-To: <A2613BDC-7577-4BED-8AB5-4799973A1586@ericsson.com>
From: Yoav Weiss <yoav@yoav.ws>
Date: Wed, 6 May 2020 10:03:47 +0200
Message-ID: <CACj=BEivQgTBrznaHjmdgOP+1O9fRR7xtX2m_u3JMV4eGfkqFQ@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, "draft-ietf-httpbis-client-hints.all@ietf.org" <draft-ietf-httpbis-client-hints.all@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000025580905a4f63566"
Received-SPF: pass client-ip=2a00:1450:4864:20::232; envelope-from=yoav@yoav.ws; helo=mail-lj1-x232.google.com
X-W3C-Hub-Spam-Status: No, score=-8.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1jWF2N-00026E-Va 855fd321778446cc039f632371942be1
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Genart last call review of draft-ietf-httpbis-client-hints-13
Archived-At: <https://www.w3.org/mid/CACj=BEivQgTBrznaHjmdgOP+1O9fRR7xtX2m_u3JMV4eGfkqFQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37577
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>

On Tue, May 5, 2020 at 8:51 PM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi Yoav,
>
> I have not received the pull request yet, so I will comment only based on
> your e-mail reply :)
>

Apologies for the delay. PR is now up at
https://github.com/httpwg/http-extensions/pull/1171


>
> In general, I am happy with your explanations, and for most parts I think
> some text giving the explanations in the draft would be useful.
>
> -------
>
> Major issues:
>
> MaQ1:
>
> >> Section 2.1. describes sending of Client Hints, based on Accept-CH, and
> Section 3.1. defines the Accept-CH header field.
> >>
> >> First, there is no guidance on what a client does BEFORE it receives
> Accept-CH.
> >> I assume it does not include support of any features.
> >>
> >> Second, there is no guidance on what a client does if it does NOT
> receive
> >> Accept-CH (because the server does not support it). Will it then send
> another
> >> request and include supported features ? What if it is too late, and
> the server
> >> has already made choises?
> >>
> >> I think some client behavior guidance would be useful.
> >
> > Generally, without an opt-in (either before Accept-CH is received or
> when the server does not support it), clients SHOULD NOT send high-entropy
> hints, but MAY send low-entropy ones.
>
> I think some guidance text would be useful.
>
> ---
>
> MaQ2:
>
> >> Related to Q3, there is not server procedure on when Accept-CH is sent
> to the
> >> client. Also, can an Accept-CH with updated information be sent?
> >
> > Servers which wish to receive client information through Client Hints
> SHOULD add Accept-CH to their responses as early as possible.
> > Later Accept-CH response headers with updated information will override
> a previous opt-in.
>
> Some text would be useful for both cases above.
>
> ---
>
> MaQ3:
>
> >> Related to MaQ2, what happens if a server receives hints that it does
> not
> >> understand, or does not support?
> >
> > Servers SHOULD ignore hints they do not understand or do not support.
>
> Is there are reason for not using MUST? SHOULD typically means
> MUST-unless-X. What would X be?
>
> Is there a way for the server to indicate to the client that it did not
> understand/support the hints? Whatever the answer, I think it would be good
> to have some text about that.
>

There's no such a mechanism, similar to other request headers.
Do you have sample text in mind that may make that point clearer?


>
> ---
>
> MaQ4:
>
> >> Section 3.1 says:
> >>
> >>   “It SHOULD be persisted and bound to the origin to enable delivery of
> Client
> >>   Hints on subsequent requests to the server's origin.”
> >>
> >> …and the subsequent text then gives an example.
> >>
> >> First, what is the time scope of “subsequent requests”? A session? An
> hour? A
> >> day? For how long does the client need to remember the Accept-CH header
> field
> >> value for a given origin server?
> >
> > A session, so similar lifetime properties as session cookies.
>
> Add some text, please :)
>
> >> Second, the procedure does not seem to take into account that certain
> aspects,
> >> e.g., network characteristics, may change between when requests are
> sent to an
> >> origin server.
> >
> > It is the server preference that's persisted, not the specific
> information. Varying client characteristics will result in varying Client
> Hints request headers at different points in time.
>
> Ok.
>
> --------
>
> Minor issues:
>
> MiQ1:
>
> >> Section 1 described that proactive content negotiation allows servers to
> >> silently fingerprint the user agent.
> >>
> >> But, later in the Section it is described that Client Hints also allow
> a server
> >> the perform fingerprinting, and the Security Considerations also say
> that there
> >> is really no difference.
> >>
> >> So, does Section 1 need to talk about fingerprinting at all?
> >
> > Section 1 describes the fact that traditional (read: pre-Client Hints)
> content negotiation methods relied on sending information to all servers,
> which enabled passive fingerprinting,
> > and how Client Hints breaks away from that paradigm, by only sending
> (high entropy) hints when the server needs them and opts-in to receive them.
>
> A server can request the hints even if it doesn't "need" them, but it
> wants to do fingerprinting. The client does not know what the server will
> do with the information.
>
> My point is that the reader should not get an impression that client hints
> somehow prevents fingerprinting. It doesn't. The only difference is that
> the server has to ask for the information.
>

Current draft includes " Client Hints mitigate ... privacy concerns of
passive fingerprinting by requiring explicit opt-in and disclosure of
required headers by the server through the use of the Accept-CH response
header."
Should that be clearer?


> ---
>
> MiQ2:
>
> >> The 4th last paragraph of Section 1 says:
> >>
> >>   “It also defines guidelines for content negotiation mechanisms that
> use it,
> >>   colloquially referred to as Client Hints.”
> >>
> >> The 2nd last paragraph of Section 1 says:
> >>
> >>   “This document defines Client Hints, a framework that enables servers
> >>     to opt-in to specific proactive content negotiation features,
> >>     adapting their content accordingly.”
> >>
> >> The 2nd last pargraph also talks about “usage of infrastructure”, which
> I don’t
> >> really understand. I assume you mean the Client Hints framework?
> >>
> >> First, I think the text in the 4th last paragraph should be replaced by
> the
> >> text in the 2nd last paragraph.
> >>
> >> Second, I think the text introducing the framework should come BEFORE
> the text
> >> introducing the Accept-CH header field.
> >>
> >> Something like:
> >>
> >>   "This document defines Client Hints, a framework that enables servers
> >>   to opt-in to specific proactive content negotiation features,
> >>   adapting their content accordingly. This document also defines a new
> >>   response header, Accept-CH, that allows an origin server to explicitly
> >>   ask that clients send these headers in requests.
> >>
> >>   Client Hints mitigate performance concerns by assuring that clients
> >>   will only send the request headers when they're actually going to be
> >>   used, and privacy concerns of passive fingerprinting by requiring
> >>   explicit opt-in and disclosure of required headers by the server
> >>   through the use of the Accept-CH response header.
> >>
> >>   The document does not define specific usages of Client Hints. Such
> usages
> >>   Need to be defined in their respective specifications.
> >>
> >>   One example of such usage is the User Agent Client Hints [UA-CH]."
> >
> > Makes sense.
>
> Thanks! :)
>

Added a small tweak on "guidelines for content negotiation mechanisms that
use the framework".
You can review the PR to see if that works.

-------
>
> Nits/editorial comments:
>
> EdQ1:
>
> >> The document uses both “client” and “user agent” terminology. Is there
> a reason
> >> for that, or could one be picked?
> >
> > No reason in particular. We can probably stick to "client".
>
> Sounds good :)
>
> Thanks!
>
> Regards,
>
> Christer
>
>