Subject: [Gen-art] Genart last call review of draft-ietf-httpbis-client-hints-13

From: Christer Holmberg via Datatracker <[email-masked]>
Date: Fri, 01 May 2020 15:44:11 -0700

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.

---

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?

---

MaQ3:

Related to MaQ2, what happens if a server receives hints that it does not
understand, or does 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?

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.

--------

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?

---

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

-------

Nits/editorial comments:

EdQ1:

The document uses both “client” and “user agent” terminology. Is there a reason
for that, or could one be picked?

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 May 2020 22:46:14 +0000

Hi,

Seems like I did a copy/paste error. Please skip Q3-Q6, the issues/questions will come later in the review.

Regards,

Christer

On 02/05/2020, 1.44, "last-call on behalf of Christer Holmberg via Datatracker" <[email-masked] on behalf of [email-masked]> wrote:

    

    
    
    Q3:

    

    ---
    
    Q4:

    ---
    
    Q5:

    ---
    
    Q6:
    
    Section 3.1 says:

    

    -------
    
    Major issues:
    
    MaQ1:

    

    ---
    
    MaQ2:

    ---
    
    MaQ3:

    ---
    
    MaQ4:
    
    Section 3.1 says:

    

    --------
    
    Minor issues:
    
    MiQ1:

    
    
    ---
    
    MiQ2:

    

    

    Something like:

    

    -------
    
    Nits/editorial comments:
    
    EdQ1:

    
    -- 
    last-call mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/last-call

---

From: Yoav Weiss <[email-masked]>
Date: Tue, 5 May 2020 09:17:15 +0200

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.

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

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

> understand, or does not support?

Servers SHOULD ignore hints they do not understand or do not support.

> value for a given origin server?

A session, so similar lifetime properties as session cookies.

> e.g., network characteristics, may change between when requests are sent

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.

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

>    One example of such usage is the User Agent Client Hints [UA-CH]."

Makes sense.

> for that, or could one be picked?
No reason in particular. We can probably stick to "client".

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 5 May 2020 18:51:36 +0000

Hi Yoav,

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

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

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

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

---

> A session, so similar lifetime properties as session cookies.
 
Add some text, please :)

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

---

>>   One example of such usage is the User Agent Client Hints [UA-CH]."
 
Thanks! :)

-------

Nits/editorial comments:

> No reason in particular. We can probably stick to "client". 

Sounds good :)

Thanks!

Regards,

Christer

---

From: Yoav Weiss <[email-masked]>
Date: Wed, 6 May 2020 10:03:47 +0200

> I have not received the pull request yet, so I will comment only based on

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

> > 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:
>
> 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?

> >>   One example of such usage is the User Agent Client Hints [UA-CH]."

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

-------

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 6 May 2020 12:43:41 +0000

Hi Yoav,

> Apologies for the delay. PR is now up at https://protect2.fireeye.com/v1/url?k=0a42e34e-54e25920-0a42a3d5-
> 869a14f4b08c-11c3f32cbd74f2f2&q=1&e=978d85da-fab3-4523-a8d9-447aa6bdf056&u=https://github.com/httpwg/http-extensions/pull/1171
 
Thanks!

I think it looks ok.

BTW, are high-entropy and low-entropy defined and well-known HTTP terms?
 
---

> Do you have sample text in mind that may make that point clearer?
 
Maybe just a note pointing out that there is no mechanism for a server to inform a client whether it understands and supports the hints.

---

Minor issues:

MiQ1:

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

Yes, I think it is better.

-------

Regards,

Christer

---

From: Yoav Weiss <[email-masked]>
Date: Wed, 6 May 2020 15:20:00 +0200

On Wed, May 6, 2020 at 2:43 PM Christer Holmberg <
[email-masked]> wrote:

> https://protect2.fireeye.com/v1/url?k=0a42e34e-54e25920-0a42a3d5-
> >
> 869a14f4b08c-11c3f32cbd74f2f2&q=1&e=978d85da-fab3-4523-a8d9-447aa6bdf056&u=

I'm not sure. The browser processing model defines a list of low-entropy CH
headers:
https://wicg.github.io/client-hints-infrastructure/#low-entropy-table
I could point at that.

> Maybe just a note pointing out that there is no mechanism for a server to
> inform a client whether it understands and supports the hints.
>
> ---
>
> Minor issues:
>
> MiQ1:
>
> >> 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.
> >

---

From: Yoav Weiss <[email-masked]>
Date: Thu, 7 May 2020 12:02:12 +0200

Addressed the latest points in the PR. Thanks! :)

On Wed, May 6, 2020 at 3:20 PM Yoav Weiss <[email-masked]> wrote:

> I'm not sure. The browser processing model defines a list of low-entropy
> CH headers:
>> >> 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.
>> >

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 May 2020 09:07:42 -0400

Please post a revised I-D when you’re ready; thanks.

Barry

On Thu, May 7, 2020 at 6:02 AM Yoav Weiss <[email-masked]> wrote:

>>> Maybe just a note pointing out that there is no mechanism for a server
>>> to inform a client whether it understands and supports the hints.
>>>
>>> ---
>>>
>>> Minor issues:
>>>
>>> MiQ1:
>>>
>>> >> 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,

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 May 2020 13:15:06 +0000

Hi,

The PR looks good to me! Thanks for addressing my issues! :)

Regards,

Christer

From: Yoav Weiss <[email-masked]>
Date: Thursday, 7 May 2020 at 13.02
To: Christer Holmberg <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, HTTP Group <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Genart last call review of draft-ietf-httpbis-client-hints-13

On Wed, May 6, 2020 at 3:20 PM Yoav Weiss <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, May 6, 2020 at 2:43 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi Yoav,

> 869a14f4b08c-11c3f32cbd74f2f2&q=1&e=978d85da-fab3-4523-a8d9-447aa6bdf056&u=https://github.com/httpwg/http-extensions/pull/1171<https://protect2.fireeye.com/v1/url?k=6272da56-3cd23ac2-62729acd-86d2114eab2f-315dfc5e8e3bb7de&q=1&e=7281b4e2-8b12-45aa-b9cc-269841f1ac96&u=https%3A%2F%2Fgithub.com%2Fhttpwg%2Fhttp-extensions%2Fpull%2F1171>

Thanks!

I think it looks ok.

I'm not sure. The browser processing model defines a list of low-entropy CH headers: https://wicg.github.io/client-hints-infrastructure/#low-entropy-table<https://protect2.fireeye.com/v1/url?k=6a29e40a-3489049e-6a29a491-86d2114eab2f-5ccf1f3eadf9c7d7&q=1&e=7281b4e2-8b12-45aa-b9cc-269841f1ac96&u=https%3A%2F%2Fwicg.github.io%2Fclient-hints-infrastructure%2F%23low-entropy-table>
I could point at that.

---

---

Minor issues:

-------

Regards,

Christer

---

From: Yoav Weiss <[email-masked]>
Date: Fri, 8 May 2020 06:33:58 +0200

> Please post a revised I-D when you’re ready; thanks.

Will do as soon as the PR
<https://github.com/httpwg/http-extensions/pull/1171> is approved and
landed.

>>>> >> 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.
>>>> >>
>>>> > Current draft includes " Client Hints mitigate ... privacy concerns
>>>> of passive fingerprinting by requiring explicit opt-in and disclosure of

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 21 May 2020 09:45:50 -0400

Christer, thanks for your review. Yoav, thanks for addressing the comments. I entered a No Objection ballot.

Alissa

> On May 1, 2020, at 6:44 PM, Christer Holmberg via Datatracker <[email-masked]> wrote:
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art