Re: WWW-Authenticate proposal: timeout flag

[Rafal Pietrak <[e-mail]>]

Hello everybody,

Thank you again for you time spent on reviewing my original submission.

I've just made new revision of my I-D, based on that review. It is now
available at: https://datatracker.ietf.org/doc/draft-pietrak-cookie-scope/

Like last time, I'll be very grateful if someone can have a look and
comment on it's viability and usefulness.

With best regards,

Rafał Pietrak

W dniu 30.04.2021 o 20:12, Rafal Pietrak pisze:
> 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