Hi Adam, it's great to see this coming together so well.<br><br><br>On Fri, Feb 12, 2010 at 9:49 PM, Adam Barth <span dir="ltr"><<a href="mailto:cap-talk@adambarth.com">cap-talk@adambarth.com</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Fri, Feb 12, 2010 at 6:13 AM, Mark Seaborn <<a href="mailto:mseaborn@chromium.org">mseaborn@chromium.org</a>> wrote:<br>
> On Thu, Feb 11, 2010 at 3:39 PM, Adam Barth <<a href="mailto:cap-talk@adambarth.com">cap-talk@adambarth.com</a>> wrote:<br>
>> For servers that do use cookies for security, servers SHOULD use a<br>
>> redundant form of authentication, such as HTTP authentication or TLS<br>
>> client certificates.<br>
><br>
> Don't these both introduce ambient authority as well?<br>
<br>
</div>Yes. Is there something specific you think would be better to<br>
recommend? In general, I wanted to point to things with RFCs in the<br>
"general recommendations" section.<br>
<div class="im"><br>
> Why use redundant authentication? If I log in with a password to get a<br>
> cookie, why should I log in with a password via HTTP authentication as well?<br>
<br>
</div>HTTP authentication has the virtue of better integrity protection than<br>
cookies. For example, there isn't a way (that I know of) for an<br>
active network attacker to force your HTTP auth credentials (at least<br>
over HTTPS), but there is a way to overwrite your cookies.<br>
<br>
The way I would imagine this working is that you'd login via HTTP<br>
auth, which would then set a cookie (e.g., a session cookie).<br>
<div> </div></blockquote><div>Perhaps it could be clearer that these other ambient authority systems help address weaknesses that cookies have aside from ambient authority, but that they do not help avoid the ambient authority problems of cookies.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
> AFAIK, TLS client certs aren't very usable, but then I've never set one up.<br>
> Would I be right in thinking that TLS client certs get sent to any server<br>
> that requests a cert, as with SSH public keys? This would make them a more<br>
> broadly-scoped form of ambient authority than cookies and HTTP auth.<br>
<br>
</div>That might or might not be how browsers work today, but there's<br>
nothing inherent in the design of TLS client certs that forces this to<br>
be the case. I suspect we'll see some more innovation in client certs<br>
to make them easier to use and to have better privacy properties. <br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
>> 7.2. Ambient Authority<br>
>><br>
>> If a server uses cookies to authenticate users, a server might suffer<br>
>> security vulnerabilities because user agents occasionally issue HTTP<br>
>> requests on behalf of remote parties (e.g., because of HTTP redirects<br>
>> or HTML forms).<br>
><br>
> Not sure if you're looking for feedback on the wording, but this reads as<br>
> somewhat vague. How about: "A server that uses cookies to authenticate<br>
> users can suffer from security vulnerabilities because user agents provide<br>
> mechanisms that allow one party to issue HTTP requests on behalf of<br>
> another. These mechanisms include HTTP redirects and HTML forms."<br>
<br>
</div>I've adopted a variant of the text you propose:<br>
<br>
[[<br>
<div class="im">A server that uses cookies to authenticate users can suffer<br>
</div>security vulnerabilities because some user agents let remote parties<br>
issue HTTP requests from the user agent (e.g., via HTTP redirects and<br>
HTML forms).<br>
]]<br>
<div class="im"><br>
>> User agents can mitigate this issue to some degree by<br>
>> providing APIs for suppressing the Cookie header on outgoing<br>
>> requests.<br>
><br>
> You're referring to UMP here?<br>
<br>
</div>Yes, UMP is an example of such an API. The point is more general<br>
though. For example, you might want a content security policy that<br>
blocks all outgoing cookies. For example, the "no-outgoing-cookies"<br>
directive I proposed here:<br>
<br>
<a href="https://wiki.mozilla.org/Security/CSP/Strawman" target="_blank">https://wiki.mozilla.org/Security/CSP/Strawman</a><br>
<div class="im"><br>
>> Although this security concern goes by a number of names (e.g.,<br>
>> cross-site scripting and cross-site request forgery),<br>
><br>
> Cross-site scripting is caused by failure to escape strings, not by cookies.<br>
<br>
</div>Perhaps in the proximate, but (as Mark is fond of point out) you can<br>
run untrusted script in your web page as long as that script can't<br>
abuse ambient authority. Some of that authority comes from the<br>
location bar at the top of the window, but much of it comes from<br>
<div class="im">cookies.<br>
<br></div></blockquote><div>I also find this connection to cross site scripting confusing. Mentioning it raises more questions that need to be explained. I would also recommend dropping it. CSRF is the clear case.<br><br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
>> the issue stems<br>
>> from cookies being a form of ambient authority. Cookies encourage<br>
>> server operators to separate designation (in the form of URLs) from<br>
>> authorization (in the form of cookies). Disentangling designation<br>
>> and authorization can cause the server and its clients to become<br>
>> confused deputies and undertake undesirable actions.<br>
><br>
> Again, I'm not sure how much depth you want to go into, but you could define<br>
> (or refer to definitions of) ambient authority and confused deputies.<br>
<br>
</div>I'm not sure how to do non-normative citations in an RFC. I'll ask<br>
around to see what the best way to do this is.<br>
<div class="im"><br>
>> Instead of using cookies for authorization, server operators might<br>
>> wish to consider entangling designation and authorization by treating<br>
>> URLs as object-capabilities.<br>
><br>
> I think "object-capability" is reserved for references that are unforgeable<br>
> (OS and language caps), not merely unguessable, but I'm not sure of the<br>
> exact definitions people have settled on.<br>
<br>
</div>I'm happy to use whatever word is most accurate here.<br></blockquote><div><br>I think just "capabilities" here might be best. The term I normally use when speaking precisely is "cryptograohic capabilities". Others on this list have objected to that on reasonable grounds. "Password capabilities" is unfortunately inappropriate because of its history. "Sparse capability" is accurate and has no misleading bindings that I know of. However, it has become obscure. Note that web-keys by themselves are not cryptographic capabilities, as I explain at <<a href="http://lists.w3.org/Archives/Public/www-tag/2010Feb/0118.html">http://lists.w3.org/Archives/Public/www-tag/2010Feb/0118.html</a>> and <<a href="http://lists.w3.org/Archives/Public/www-tag/2010Feb/0119.html">http://lists.w3.org/Archives/Public/www-tag/2010Feb/0119.html</a>>.<br>
<br>Altogether, I think the phrase "treating URLs as capabilities" is simply fine. It makes no strong statement that these URLs are capabilities.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
>> 7.3. Clear Text<br>
>><br>
>> The information in the Set-Cookie and Cookie headers is transmitted<br>
>> in the clear.<br>
><br>
> Not if they're sent over HTTPS.<br>
<br>
</div>Fixed.<br>
<div class="im"><br>
>> Servers SHOULD encrypt and sign their cookies.<br>
><br>
> It sounds like you're saying that servers should encrypt cookies-at-rest --<br>
> those stored in a database. Otherwise I am not sure if you're saying:<br>
> * cookies should only be sent over an encrypted channel, or<br>
> * cookies should consist of encrypted data.<br>
<br>
</div>I've changed this to the following:<br>
<br>
[[<br>
Servers SHOULD encrypt and sign their cookies when transmitting<br>
them to the user agent (even when sending the cookies over a secure<br>
channel).<br>
]]<br>
<div class="im"><br>
>> 7.4. Weak Confidentiality<br>
>><br>
>> Cookies do not provide isolation by port. If a cookie is readable by<br>
>> a service running on one port, the cookie is also readable by a<br>
>> service running on another port of the same server. If a cookie is<br>
>> writable by a service on one port, the cookie is also writable by a<br>
>> service running on another port of the same server.<br>
><br>
> I didn't know that. I suppose this ties in with your "Beware of<br>
> Finer-Grained Origins" paper. Does this mean that there is little point in<br>
> considering origins to be <scheme, domain, port> tuples instead of being<br>
> synonymous with domain names?<br>
<br>
</div>Well, the isolation by scheme is super important. Without that, HTTPS<br>
wouldn't provide any protection from active network attackers. Also,<br>
there's more to secure in the browser than just cookies. Cookies have<br>
weaker protections than most browser privileges because they're old.<br>
<div class="im"><br>
> For example, the Web Geolocation API says that the browser should display<br>
> the requester's origin when prompting the user, where "origin" is defined by<br>
> HTML 5 to include the port number. Firefox 3.5 apparently violates this by<br>
> not displaying the port number. I am sure this is of no consequence for<br>
> most users, for whom port numbers are not meaningful. This property of<br>
> cookies seems like another reason not to care -- at least for sites that use<br>
> cookies.<br>
<br>
</div>I wouldn't use cookies as a model when designing new security<br>
features. Port-based isolation isn't hugely valuable, but it's the<br>
model we've got. There some value in not introducing gratuitous<br>
complexity when designing new features. (Sadly, we're stuck with some<br>
pretty complex old features.)<br>
<div class="im"><br>
>> For this reason,<br>
>> servers SHOULD NOT both run mutually distrusting services on<br>
>> different ports of the same machine and use cookies to store<br>
>> security-sensitive information.<br>
><br>
> It's OK to do it on the same machine (i.e. IP address) if different domain<br>
> names are used, I think.<br>
<br>
</div>Good point. I've changed "machine" to "host".<br>
<br>
Thanks for your detailed comments.<br>
<font color="#888888"><br>
Adam<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
cap-talk mailing list<br>
<a href="mailto:cap-talk@mail.eros-os.org">cap-talk@mail.eros-os.org</a><br>
<a href="http://www.eros-os.org/mailman/listinfo/cap-talk" target="_blank">http://www.eros-os.org/mailman/listinfo/cap-talk</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Text by me above is hereby placed in the public domain<br><br> Cheers,<br> --MarkM<br><br>