Re: WWW-Authenticate proposal: timeout flag

[Rafal Pietrak <[e-mail]>]

Hell,

Thank your for the review.

Before I'd address your comments, I'd say, that:

1. I'm opened to any suggestions and I'd like to forge the proposal as
useful (for the purpose intended) and possible - even when a complete
rewrite would be necessary.

2. The intention is to allow for multiple security www contexts being
available for a user at his/her web-browser. .... and that not at the
URL level.

W dniu 30.04.2021 o 18:00, Daniel Veditz pisze:
> One thing that jumped out at me was the Viewport visibility overriding
> the specified Domain. Don't do that! Either make setting a too-broad

OK.

As you can imagine, my intention was to close any possible leakage of
cooqies with security tokens.

But, would you think that stating that: "any Viewport element with
'domain' different then domain of the cookie with radius attribute set
MUST by omitted from 'fetch-list'"? (the "fetch-list" to be defined as
all the "remote" elements of document in viewport).

> domain an error and reject the cookie (as we did with __Host- prefixed
> cookies), or accept that the server knows what it's doing and honor the
> domain. If, as a web author, you restrict cookies to a viewport you
> still might have all kinds of sub-resource requests from sibling origins
> in the same domain. Why break that?

I don't think my proposal would break anything. I think, that a web
author, with *new* tool to setup a security-session of his/her web-page
can conform to any well defined standard.

On the other hand, I tried to think of any way, the new attribute could
possibly break current services, and I think I've eliminated all of
them. If not I'd prefer to modify the proposal around the other
(WORLD/WINDOW) values to have them guarantee undisturbed work in today's
use scenario.

So, I'd rather opt for the requirement, that all who'd like to use the
new attribute for session logging SHOULD restrict all subresources to
the domain of the session cookie with viewport radius. ... then loosen
constraints and exorcise some unforeseen security holes.

Naturally, I may be too cautious. May be this requires some more examples??

> 
> It's the "Secure" attribute, not "SecureOnly"

Right. :)

> 
> 4 different visibility levels sounds like a PITA to implement, or even
> define. If a site is using "Tabs" visibility and they do a

I think, inclusion of examples in the document could clearify the specs.
I will do that in next revision.

> window.open(<same-origin>), does it have the same cookies or not? That

window.open(same_origin) should work (with current proposal). It goes
into the same origin as defined in cookie in question, so cookie should
be delivered to the server as expected, and all should work be fine.

> used to be a popup, so new window == no cookies. In the last decade o> so browsers (only one kind of user agent) have converged on having that
> be a new tab in the same window (has cookies). If the author specifies
> size attributes then it's back to a separate window (no cookies). But

I this case my intention would be to popup the window *without* viewport
cookie. Consequently, popups wouldn't work with "tight cookie security".
For a web designer, there are two workarounds:
1. put credentials into URL of the popup.
2. use modal-pane within the original viewport.

Both workarounds are "simple", and I believe cover vast majority of use
cases.

> that's not part of the HTML specifications, it's just conventions that
> User Agents have adopted. It would be better to define a cookie spec
> based on concepts that are specified somewhere and aren't just
> conventions. You need to come up with some compelling reasons for why
> each of the levels is necessary and when it would be useful.

OK. I'll do the in next release.

> 
> Please restrict this to "session" cookies (no set expiration time). I
> don't know how I'd store a "Viewport" cookie (on disk, between browser
> runs if it has a long expiration) that makes sense after you close that
> one viewport. Or tab, or window.

OK. Very good point, I didn't thought of that.

> 
> Would your use-cases be served by the HTML "sessionStorage" feature?
> It's not sent in HTTP requests so it's definitely not the same, but that
> is explicitly scoped to the current document and not shared with other
> documents of the same origin (similar to your Viewport, but excludes
> same-origin frames).

No, it wouldn't. The goal is to replace "security-tokens" today
maintained within URL of the page. That (current - to be obsoleted)
method allows for web-links (the "a href=") on such page to be correctly
executed by browsers even without JavaScript. This is very desirable.

On the other hand, security Tokens kept in sessionStore have to be
retrieved, and put into the GET headers by a script. This is
undesirable. Security cookies would most likely be httpOnly, and in such
case that would be just impossible.

I hope this explanation make sense. But pls comment if you don't agree.

BR

-Rafał

> 
> -Dan Veditz
> 
> On Fri, Apr 30, 2021 at 4:37 AM Rafal Pietrak <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     Hi everyone,
> 
>     W dniu 29.04.2021 o 22:50, Soni L. pisze:
>     >
>     >
>     > On 2021-04-29 5:42 p.m., Daniel Stenberg wrote:
>     >> On Thu, 29 Apr 2021, Soni L. wrote:
>     >>
>     >>> We'd like to be able to specify a timeout value for
>     WWW-Authenticate,
>     >>> in particular `timeout=0` so the HTTP authentication can be
>     converted
>     >>> into session cookies rather than sending the password in plaintext
>     >>> (sure, it gets sent over TLS, but that doesn't matter) on every
>     >>> request. Would anyone be interested in such proposal?
>     >>
>     >> What should happen when the time runs out? Is that just an ask to the
>     >> client that it should drop the auth status at that point?
>     >>
>     >> I don't think this is enough to make people stop using cookies for
>     >> logged in session status even if you would get someone to adopt.
>     >>
>     >
>     > It's to stop using forms, not cookies. Cookies are more secure because
>     > they don't keep re-sending the password such that a malicious or
>     > compromised server could exfiltrate the plaintext. Using cookies for
>     > logged in session status is a good thing.
>     >
> 
>     Still, cookies have their problems.
> 
>     Would somebody be so kind and have a look at my proposal regarding
>     cookies at:
>     https://datatracker.ietf.org/doc/draft-pietrak-cookie-scope/
>     <https://datatracker.ietf.org/doc/draft-pietrak-cookie-scope/>
> 
>     ... and naturally give it a comment or two :)
> 
>     Best regards,
> 
>     -R
>     -- 
>     Rafał Pietrak
> 

-- 
Rafał Pietrak