Re: [Last-Call] Genart last call review of draft-ietf-httpbis-client-hints-13
Yoav Weiss <yoav@yoav.ws> Wed, 06 May 2020 08:04 UTC
Return-Path: <yoav@yoav.ws>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505303A07D8 for <last-call@ietfa.amsl.com>; Wed, 6 May 2020 01:04:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 nyX0KC1tBRRp for <last-call@ietfa.amsl.com>; Wed, 6 May 2020 01:04:06 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 3BE223A053F for <last-call@ietf.org>; Wed, 6 May 2020 01:04:06 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id l19so1313276lje.10 for <last-call@ietf.org>; Wed, 06 May 2020 01:04:05 -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=VSgLPxyWHJb8ipseiXb2gewQoRthDNO7vHkorXpAC3fL3slxRw2Nmdv6m5KM9d2YXt T3FGFtSG346xNNsP1NzX6UO2tDOXgg+oj/A+8qKMjeEXbzWz1uFzch0Seq1CcfdCSnh2 Drp3oz0DQxvIFpMdnTUWHv3zYKEIQFMFKYNaCulvpnRQ1zByMXYCPvPKNmqQzFlsVH8F 8Nz9TEHEMYSrnN6y5991Fp3GfUW710A09thUtaPjoaN0aOC1LT4uMnXOGqjktGmMywz9 OwJSQUnh29yKrwFecLuqH6/Sv9XRC/3khZg6EHRwfz97WGmbv35njDI0eXV81sTL9gmk 24Aw==
X-Gm-Message-State: AGi0Pubs4iBqcODTAlcFIJZ9kYboBPy9Dji65tGA/Ta3QkjcIFkacPwn S2kRhicpU3wfeiNHhDZAAe63G/Tc6tYCi8P6A8KP3g==
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, 06 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"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/Uh8C6oGwiypE81YzTLjsbAnegsg>
Subject: Re: [Last-Call] Genart last call review of draft-ietf-httpbis-client-hints-13
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 May 2020 08:04:09 -0000
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 > >
- [Last-Call] Genart last call review of draft-ietf… Christer Holmberg via Datatracker
- Re: [Last-Call] Genart last call review of draft-… Christer Holmberg
- Re: [Last-Call] Genart last call review of draft-… Yoav Weiss
- Re: [Last-Call] Genart last call review of draft-… Christer Holmberg
- Re: [Last-Call] Genart last call review of draft-… Yoav Weiss
- Re: [Last-Call] Genart last call review of draft-… Christer Holmberg
- Re: [Last-Call] Genart last call review of draft-… Yoav Weiss
- Re: [Last-Call] Genart last call review of draft-… Yoav Weiss
- Re: [Last-Call] Genart last call review of draft-… Barry Leiba
- Re: [Last-Call] Genart last call review of draft-… Christer Holmberg
- Re: [Last-Call] Genart last call review of draft-… Yoav Weiss
- Re: [Last-Call] [Gen-art] Genart last call review… Alissa Cooper