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

Yoav Weiss <yoav@yoav.ws> Tue, 05 May 2020 07:21 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 B61CC3A159F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 5 May 2020 00:21:09 -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 a8recwOkhCSl for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 5 May 2020 00:21:07 -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 82D723A0DC8 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 5 May 2020 00:21:07 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jVrpr-0002Ev-LY for ietf-http-wg-dist@listhub.w3.org; Tue, 05 May 2020 07:17:47 +0000
Resent-Date: Tue, 05 May 2020 07:17:47 +0000
Resent-Message-Id: <E1jVrpr-0002Ev-LY@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <yoav@yoav.ws>) id 1jVrpq-0002E5-6J for ietf-http-wg@listhub.w3.org; Tue, 05 May 2020 07:17:46 +0000
Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <yoav@yoav.ws>) id 1jVrpn-0003qi-Pq for ietf-http-wg@w3.org; Tue, 05 May 2020 07:17:46 +0000
Received: by mail-lf1-x131.google.com with SMTP id d25so482135lfi.11 for <ietf-http-wg@w3.org>; Tue, 05 May 2020 00:17:43 -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=VP+tY8xeqhbHRPBAde6r67IdOA8XV3vB+dxH7RBIFvA=; b=QhBKgteCbcUdsiDYoOgefCfR3iiqFB3uzavCtZoExCU3kgcewsDJQbQPbFDE7qypLp Y1KQ7vKxU+gML1IWEgjmwk5jw6om8gWyes073gxM019mOu8VHJMnt8d90D/Kwa5vVreW l6vIUl+ZNJSnYFqhpFVUOyxvog9wcozerC1ZVQVsciUBA2sWzabUfGBE6/39Bh1e1jTV hU3qw7xchHAcnLSShExYszuL7RvFjbCK+8wJsJt1jYn740pm2lsu+u/04oJQ0Z9zT95K 0bsLFtTFHlzIQcj81FgoPBlQZXtdHQ0PZPNN1yF8Xfg0VYr0/BU8P+U1Dg7Ym/Vz1zKz ttGA==
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=VP+tY8xeqhbHRPBAde6r67IdOA8XV3vB+dxH7RBIFvA=; b=bmYPLNufkFpPKyD47hhXAXL8+cCN9rpHwVRAbgRI79ryJHMMdIm5WVGK+u5TAt3xwz TsI/+ST3OjmuV1ecBr1djTETe55524JytfsHQlxxlgOGfGJqpSnavF1SPHM8uXh6Fd2N 0kyb0thDGnKror2KFnfLg1+OGlxq37+raz1u/ASQAyUlk+jX1CPOgxDdvWPaNvd0GCET ioevjnM7KkF6n9dmoIeNMxL6OA1xiT1u8WX0XLj2laFEqBnXTp9oPIW96EiSHn/t8kqS BtBing7yVdfKEirE7fzk+y3uwVWbKxfEh1OrDz68JZx98eK1SW6rHsf7weJlNtj/3pik eUWA==
X-Gm-Message-State: AGi0PuYdIlDkka19/DIGe8QH1/I7Kp16QJN3AaY3ISyunf6+XEpPBR4v P2xpcDHc7fETlpKjHo+aM+4MUW0LT+8BPwP0/GA5SQ==
X-Google-Smtp-Source: APiQypLvP/X6Aawy5hTyOgxl7ksooUAgaMGhYivYv8UpD727D3m9QlrVFsTaG3a7RUjSbWrhTVIELMCwTCBHJoPVVtA=
X-Received: by 2002:a19:c749:: with SMTP id x70mr715973lff.207.1588663051582; Tue, 05 May 2020 00:17:31 -0700 (PDT)
MIME-Version: 1.0
References: <158837305177.24719.21462684096579298@ietfa.amsl.com>
In-Reply-To: <158837305177.24719.21462684096579298@ietfa.amsl.com>
From: Yoav Weiss <yoav@yoav.ws>
Date: Tue, 5 May 2020 09:17:15 +0200
Message-ID: <CACj=BEhNqVRxQagFmJ4sbXrn=YOWAYPBqODw_rL7MZbUDjNq5w@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: gen-art@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
Content-Type: multipart/alternative; boundary="000000000000db96d605a4e17049"
Received-SPF: pass client-ip=2a00:1450:4864:20::131; envelope-from=yoav@yoav.ws; helo=mail-lf1-x131.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: mimas.w3.org 1jVrpn-0003qi-Pq 2e45225422daedbaab7f17ab923e02c9
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=BEhNqVRxQagFmJ4sbXrn=YOWAYPBqODw_rL7MZbUDjNq5w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37564
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>

Thanks for reviewing! Answered your questions below. Let me know if there
are any followup questions.

I'll put together a PR that integrates your comments into the draft, and
send it your way for review.

On Sat, May 2, 2020 at 12:44 AM Christer Holmberg via Datatracker <
noreply@ietf.org> wrote:

> Reviewer: Christer Holmberg
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-httpbis-client-hints-13
> Reviewer: Christer Holmberg
> Review Date: 2020-05-01
> IETF LC End Date: 2020-05-08
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: The document is easy to read, and I understand the general
> concept of
> the mechansim. However, I have a number of questions, some related to the
> usage, which I think need to be clarified, and some more editorial.
>
> Q3:
>
> Section 2.1. describes sending of Client Hints, based on Accept-CH, and
> Section
> 3.1. defines the Accept-CH header field.
>
> But, there is no guidance on what a client does BEFORE it receives
> Accept-CH. I
> assume it does not include support of any features.
>
> Also, 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.
>
> ---
>
> Q4:
>
> Related to Q3, there is not server procedure on when Accept-CH is sent to
> the
> client.
>
> ---
>
> Q5:
>
> Related to Q4, what happens if a server receives hints that it does not
> understand, or does not support?
>
> ---
>
> Q6:
>
> 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?
>
> 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.
>
> -------
>
> 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.


>
> ---
>
> 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.


>
> ---
>
> 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.


>
> ---
>
> 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.


>
> 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.


> --------
>
> 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.


> ---
>
> 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.


>
> -------
>
> 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".