Subject: Re: June Interim: call for topics

From: Tommy Pauly <[email-masked]>
Date: Tue, 01 Jun 2021 17:11:39 -0700

Hi Meiling,

Based on the previous list discussion, this sounds like it would best be handled as an issue on the ongoing revision of the HTTP/2 spec.

Can you please file an issue to discuss the problem statement here?

https://github.com/httpwg/http2-spec/issues <https://github.com/httpwg/http2-spec/issues>

Best,
Tommy

> On May 21, 2021, at 12:38 AM, Meiling Chen <[email-masked]> wrote:
> 
> Hi Mark,
> If time permits, I'd like to add one for the topic of  http2 window size setting, 15 minutes is ok.
> 
> We describe it in detail in the draft draft-chen-httpbis-window-size-use-case-00(https://datatracker.ietf.org/doc/draft-chen-httpbis-window-size-use-case/ <https://datatracker.ietf.org/doc/draft-chen-httpbis-window-size-use-case/>).
> Meanwhile,  we proposed a solution to the problem, by define the minimum value setting mechanism of HTTP2.0 Window and Window_update, and a Window_update frame sending
> mechanism. We describe interactive <> process <> in detail in the draft draft-chen-httpbis-window-size-00 (https://datatracker.ietf.org/doc/draft-chen-httpbis-window-size/ <https://datatracker.ietf.org/doc/draft-chen-httpbis-window-size/>) .
>  
> From: Mark Nottingham <mailto:[email-masked]>
> Date: 2021-05-20 12:23
> To: [email-masked] Group <mailto:[email-masked]>
> CC: Tommy Pauly <mailto:[email-masked]>
> Subject: June Interim: call for topics
> Hi everyone,
>  
> We've roughed in an agenda for the upcoming agenda here:
>   https://httpwg.org/wg-materials/interim-21-06/agenda.html
>  
> If you have a topic you think would benefit from WG discussion, please say so. We prefer topics to be discussed on-list before we devote meeting time to them, so if you haven't already done so, please start a mailing list discussion thread first.
>  
> Cheers,
>  
>  
> --
> Mark Nottingham   https://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Jun 2021 17:01:36 +1000

Hi Felix,

That's good to hear. Please keep us in the loop, and ask if you need any help or guidance.

Cheers,

> On 22 May 2021, at 7:38 am, W. Felix Handte <[email-masked]> wrote:
> 
> Hello all,
> 
> After a somewhat long hiatus, I have recently resumed work on draft-handte-httpbis-dict-sec. I plan to get a new version up in the next couple weeks.
> 
> I don't have any specific updates that require time at the meeting, other than that I would like to resurface the topic to the group.
> 
> Thanks,
> Felix
> 
> On 5/20/21 12:23 AM, Mark Nottingham wrote:
>> Hi everyone,

---

From: Rafal Pietrak <[email-masked]>
Date: Thu, 3 Jun 2021 19:37:11 +0200

Hello Daniel and Everybody,

W dniu 21.05.2021 o 23:36, Daniel Veditz pisze:
> On Fri, May 21, 2021 at 8:03 AM Rafal Pietrak <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     If possible, I'd appreciate a couple of minutes for my cookies radius
>     proposal
>     (https://datatracker.ietf.org/doc/draft-pietrak-cookie-scope/
>     <https://datatracker.ietf.org/doc/draft-pietrak-cookie-scope/>)
> 
> 
> Mark's answer[1] to another recent cookie proposal applies here too. For

I think, I've followed those guidelines from the very beginning:
1. I've drafted my proposal
2. I've tried to get WG attention on this list.

Should there be anything else for me to do, pls advise.

> now the group is only considering cookie proposals as part of
> RFC6265bis. This is on the agenda for this meeting but your proposal
> does not yet have the support to be incorporated into it.

OK.

Although I'm responding so late, because I've tried to work my way out
into the RFC6265bis, but that proved to be more difficult then I've
initially expected, and while I haven't received much response to my
proposal, I started to feel, that even if my proposal gets through into
the RFC6265bis, It'll be in an entirely different form, that I currently
imagine. So the work of merging my draft into RFC6265bis would be a
complete waste.

For the time being I'd rather assume, that discussion around words in my
draft-01 could be more up-to-the-point, then discussion if-where-how to
incorporate it within RFC6265bis.

So, I'd appreciate if I could have a couple of minutes during the June
meeting for cookie-radius presentation.

[-----------]
> This IS the group for the topic, and anywhere else you try is likely to
> bounce you back here. What you really need to do is drum up support for
> this. Are there web sites that want to use this functionality enough to
> change their code to use it? Are there client implementers fired up to
> support Radius (browsers of course, but more than just browsers)? Is
> there only support for part of it, and if so could that be solved in a
> different way?

Different way? NO.

I tried all other approaches, may be I miss knowledge and imagination,
but I couldn't find any way joggling HTTP/cookies/Local/session-store,
that could possibly substitute security token as-part-of-URL ... keeping
the functionality of URL: different TAB -> differet URL.

If there is any, I'll be happy to walk away with it and forget the
"readius".

> 
> My own prejudice is that I would never want "World" because I don't
> trust sharing my cookies with all those other unknown apps. The
> distinction between Tabs and Windows is lost on me because in at least
> some browsers you can drag tabs or groups of tabs from window to window.
> "Viewport" as a stricter definition of how "session" is often
> interpreted by browsers might be interesting, and better backwards
> compatibility than simply redefining/clarifying the meaning of a session
> cookie.  For some uses, like banks, the existing clear-site-data feature
> might be good enough, so you'll need to sell folks on why it isn't.

I can elaborate, But basically my design follows this basic principle
line of logic:
1. a change is NECESARY -> current cookies (or any other auth mechanism)
don't provide URL-like separation of security contexts between separate
viewports.
2. So. The proposal does introduce that, keeping the definition as
minimal as possible to provide required missing functionality
3. then I turn back, and check is by just a little extra that definition
could provide more functionality (at close to none cost, like cost of
3-5 extra words to recognise)
4. if so, I put that extra into the design.

This is where "world" and "tabs" originated. The targeted functionality
does not need them, but I wouldn't bet if those COULD be liked by other
web designers. And those may come at no extra implementation cost.

To make it work, one must make sure, that those "extra" keywords are
well defined. I  have made an effort to define them well, but It's
possible I failed there. Still, I think it's worth spending time on
making them defined "perfectly". But, should that couldn't be done, let
them go away. They don't matter for the goal at hand.

If I was to make a hasty  "fine tuning" of my definitions here, I'd say:
1. "world" is basically for web-designers, that "want-to-grab-them-all"
- meaning, no matter where user turns, he/she'll always returns those
same cookies to the server - designers "may" like that. I'm not a judge
here, I wouldn't need it, but I can foresee others would.
2. "tab" cookie is possibly ill-defined. I admit. It should probably be
scratched at this point. I thought: when there is an "object", there
should be a "token/distinction" for it. But you're probably right. There
is no imaginable value in distinguishing windows from tabs.

So: would it be possible for me to have a quick (5min?) presentation of
the cookie-radius proposal during the June meeting? (Cc: to Mark
Nottingham, is to address this question to the chair of the group
formally - I'm new here, and don't really know my way around, pls
forgive if that's not appropriate)

Naturally, should there be anything I could improve in my draft, I'll be
happy to pick up from discussion here on the list, before the meeting.

-R

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 4 Jun 2021 14:20:36 +1000

Hi Rafal,

First, I'll address your question about presenting in the meeting. Generally -- and especially for cookie modifications -- we like to see on-list interest before devoting meeting time to a topic.  In the IETF, mailing lists are the primary mechanism for discussion, not meetings. So please continue to discuss this on the list; if we get to a point where meeting time is necessary to make progress, we'll schedule it.
 
Now, regarding your proposal -- As I understand it, you want to authenticate users on the server side in a way that's limited to a per-top level browsing context (e.g., window or tab). Cookies are not adequate for that purpose because servers can't distinguish cookies from two different browsing contexts in the same browser. HTML session state isn't adequate because it can't modify requests to the server (unless it does so by modifying the URL, which is clunky and arguably unreasonable).

Is that about right?

If so, I can see why you're proposing a change to cookies. However, be aware that cookies are a very widely-deployed technology with significant impact on privacy, security, and interoperability. The only way to make a change to them is to convince implementers (primarily, browsers) that the use case is so compelling that it overcomes the risks and costs of implementing it. Furthermore, to make it interoperable, you need to convince all of the browser engines to do so, and to use it, you need to wait until enough users update to the browser versions that implement it (an aspect that's more tricky because you seem to want to rely on support for a new feature to deliver some security properties that are important to you). 

In other words, it's not impossible to introduce a change like this, but it's not easy, at all. As Dan points out, you're going to need to convince people. I'd suggest that you focus on stating the requirements that you have as clearly as possible, establishing that those requirements are shared by others, and showing that they can't be met by existing approaches. The exact specification text doesn't matter very much at this stage (and may actually distract from the core issues you want to address).

This topic is suitable for this mailing list, but if there isn't more interest demonstrated here (and folks, please chime in if you have thoughts!), you might try posting about what you're trying to do on the WICG Discourse.[1] That venue is watched by a number of folks who work for browsers across the stack, and their input might help refine your proposal.

Cheers,

P.S. Did you look at using a ServiceWorker to add authentication credentials to requests, based upon the client.id of the FetchEvent? I haven't tried this, but it looks like it might be a fruitful direction, if I understand your use case correctly.

1. https://discourse.wicg.io

> On 4 Jun 2021, at 3:37 am, Rafal Pietrak <[email-masked]> wrote:
>

---

From: "Meiling Chen" <[email-masked]>
Date: Fri, 4 Jun 2021 13:41:50 +0800

Hi Tommy,
As your adivce, I create a new issue, please see in,
https://github.com/httpwg/http2-spec/issues/863 

Best,
Meiling

From: Tommy Pauly
Date: 2021-06-02 08:11
To: Meiling Chen
CC: mnot; ietf-http-wg
Subject: Re: June Interim: call for topics
Hi Meiling,

https://github.com/httpwg/http2-spec/issues

Best,
Tommy

Hi Mark,

We describe it in detail in the draft draft-chen-httpbis-window-size-use-case-00(https://datatracker.ietf.org/doc/draft-chen-httpbis-window-size-use-case/).
Meanwhile,  we proposed a solution to the problem, by define the minimum value setting mechanism of HTTP2.0 Window and Window_update, and a Window_update frame sending
mechanism. We describe interactive process in detail in the draft draft-chen-httpbis-window-size-00 (https://datatracker.ietf.org/doc/draft-chen-httpbis-window-size/) .
 
From: Mark Nottingham
Date: 2021-05-20 12:23
To: [email-masked] Group
CC: Tommy Pauly
Subject: June Interim: call for topics
Hi everyone,

 
Cheers,

---

From: Rafal Pietrak <[email-masked]>
Date: Fri, 4 Jun 2021 12:12:33 +0200

Hi Mark,

> First, I'll address your question about presenting in the meeting. Generally -- and especially for cookie modifications -- we like to see on-list interest before devoting meeting time to a topic.…

That is bad news for me, but ... that's life :(

I'll see what I can do under those circumstances.

> Now, regarding your proposal -- As I understand it, you want to authenticate users on the server side in a way that's limited to a per-top level browsing context (e.g., window or tab). Cookies are…

Yes ... and no.

It is exactly true, that I'm attempting to use cookies on a per
top-level browser context.

But I'd object, that cookies are "not adequate for that". They became
inadequate, but that's what IMHO should be mended ... and I'm trying to
put forward a simple way to do so.

As per original "goal" stated in first cookies RFC - they are there "for
the purpose of maintaining the state of 'connection' into the
'stateless' server". No mention, that user is allowed just ONE
connection to any particular service.

In the pre-www era, whenever a windows (x-windows in those days)
workstation, opening a (say: telnet) connection to remote host, it
didn't share login credentials with other windows from that
user/workstation to that remote host. Admittedly, a new terminal window
launched locally didn't require user to go through a login process
again. Those two "login-scenarios" lived side by side with each other.
Today in web environment, only the later prevailed as cookies were
introduced.

Currently (in the www/javascript/cookies world), we can only use
distinguished URI to achieve the first functionality.

So yes, that's the purpose of my proposal; and no, I strongly believe,
that cookies are perfect for that ... only when slightly improved :)

> 
> If so, I can see why you're proposing a change to cookies. However, be aware that cookies are a very widely-deployed technology with significant impact on privacy, security, and interoperability. The only way to make a change to them is to convince implementers (primarily, browsers) that the use case is so compelling that it 

Yes, I get that.

And I try (and I'm committed) to make sure the definition of
cookie-radius doesn't interfere destructively with any of today's
internet applications.

> overcomes the risks and costs of implementing it. Furthermore, to make it interoperable, you need to convince all of the browser engines to do so, and to use it, you need to wait until enough users update to the browser versions that implement it (an aspect that's more tricky because you seem to want to rely on support for a new feature to deliver some security properties that are important to you). 

Yes. This is tricky.

And I actualy hoped to find people involved in development/design of
major browsers here (on this list), and have them comment (critic, or
may be support) my proposal. I'm a little surprised, that this didn't
happen.

> In other words, it's not impossible to introduce a change like this, but it's not easy, at all. As Dan points out, you're going to need to convince people. I'd suggest that you focus on stating the…

So let take this opportunity to put my proposal in some other (short) words:
1. the goal is to let applications that still use security tokens in
URI, get them (the security tokens) out off the URI, and put them into
cookies, while preserving the context separation URI give users of those
applications.
2. The definition/modification of cookies MUST be set in such a way, as
to keep ALL current web application work unaltered.
3. The definition of the proposed cookie feature supporting above SHOULD
give web-developers means to detect a complying web browser.. so that
web application could silently migrate to new system, whenever that's
possible.

I'd really appreciate discussing those goals here ... may be after the
dust from June meeting settles (I'll ping the list then :).

> This topic is suitable for this mailing list, but if there isn't more interest demonstrated here (and folks, please chime in if you have thoughts!), you might try posting about what you're trying t…

OK. I'll try that too.

> P.S. Did you look at using a ServiceWorker to add authentication credentials to requests, based upon the client.id of the FetchEvent? I haven't tried this, but it looks like it might be a fruitful…

In principle it could be possible (although I'm not sure until I try to
code for it), but security people wouldn't let programmers install a
man-in-the-middle code to handle security tokens for sure. I'd expect
(if eventually deployed), radius-cookies will always have HttpOnly
attribute set.

Regards,

-R