Re: June Interim: call for topics

Rafal Pietrak <cookie.rp@ztk-rp.eu> Fri, 04 June 2021 10:24 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 1FE9E3A325D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 4 Jun 2021 03:24:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ztk-rp.eu
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 5xticD_uOnIt for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 4 Jun 2021 03:24:46 -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 EE1EE3A3251 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 4 Jun 2021 03:24:45 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1lp6ty-0006X8-UQ for ietf-http-wg-dist@listhub.w3.org; Fri, 04 Jun 2021 10:18:28 +0000
Resent-Date: Fri, 04 Jun 2021 10:18:06 +0000
Resent-Message-Id: <E1lp6ty-0006X8-UQ@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 <cookie.rp@ztk-rp.eu>) id 1lp6p9-00068K-K1 for ietf-http-wg@listhub.w3.org; Fri, 04 Jun 2021 10:13:14 +0000
Received: from hax2-04.wsisiz.edu.pl ([213.135.44.188] helo=zorro.ztk-rp.eu) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <cookie.rp@ztk-rp.eu>) id 1lp6p4-0001DN-2L for ietf-http-wg@w3.org; Fri, 04 Jun 2021 10:13:05 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ztk-rp.eu; s=2024; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=1Lqu6A4xyezLkaT/eqC0sDq0nVIHug0IShTaTz51n/s=; b=dk7txtcxWQp4AbDSm6XrfD7gGT Tc22qCZgVRd9qgnu8bzgpZ2aLJamcXogBVSBK0JtGks3JlTNkSscD0PXP5oCPHMq1+JLcW3qLMvgV EIObcAoM3P/BlMZqxzXkPN53FS28F8sdTMUiQ7g+NpCFwcYOwYGzBx5mZ8xG1nje7GCs=;
Received: from public-gprs414592.centertel.pl ([37.47.250.193]:13114 helo=[192.168.43.32]) by zorro.ztk-rp.eu with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <cookie.rp@ztk-rp.eu>) id 1lp6of-00Fd3b-Rw; Fri, 04 Jun 2021 12:12:43 +0200
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
References: <D3DECA17-1574-4EC7-8B21-97F2EB042276@mnot.net> <082f23bc-ea78-2f95-4c78-4f9f88d6c47d@ztk-rp.eu> <CADYDTCAnCsQeP+8umkqTQCVqa3NhJ5+4QPZMffGWPXrF7_FB4A@mail.gmail.com> <3cdc71e9-70a1-1ca9-39f3-9319c1ae291f@ztk-rp.eu> <44E80419-7895-49C7-9017-F55DF3FBAEA7@mnot.net>
From: Rafal Pietrak <cookie.rp@ztk-rp.eu>
Message-ID: <2d135f33-19a2-321f-66c8-6a92e85f471e@ztk-rp.eu>
Date: Fri, 04 Jun 2021 12:12:33 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <44E80419-7895-49C7-9017-F55DF3FBAEA7@mnot.net>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 37.47.250.193
X-SA-Exim-Mail-From: cookie.rp@ztk-rp.eu
X-SA-Exim-Version: 4.2.1 (built Sat, 13 Feb 2021 17:57:42 +0000)
X-SA-Exim-Scanned: Yes (on zorro.ztk-rp.eu)
Received-SPF: pass client-ip=213.135.44.188; envelope-from=cookie.rp@ztk-rp.eu; helo=zorro.ztk-rp.eu
X-W3C-Hub-DKIM-Status: validation passed: (address=cookie.rp@ztk-rp.eu domain=ztk-rp.eu), signature is good
X-W3C-Hub-Spam-Status: No, score=-4.7
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.59, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1lp6p4-0001DN-2L d24182a9232447d168e36cd9178f4b6a
X-Original-To: ietf-http-wg@w3.org
Subject: Re: June Interim: call for topics
Archived-At: <https://www.w3.org/mid/2d135f33-19a2-321f-66c8-6a92e85f471e@ztk-rp.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38852
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>

Hi Mark,


W dniu 04.06.2021 o 06:20, Mark Nottingham pisze:
> 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.

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

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

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

OK. I'll try that too.

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

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