Re: [http-state] IETF-wide Last Call for -httpstate-cookie-10 ?

[Daniel Stenberg <[e-mail]>]

On Thu, 26 Aug 2010, Shelby Moore wrote:

>> It is for example a rather common way to continue a "session" that
>> was begun with one HTTP client to complete it with a second one.
>
> I have no idea why you think a secure HTTPS client would want to open such a 
> security hole?

Some features in softwre can be used as features for good purposes as well as 
bad purposes. The use-cases I've had and the ones my friends have mentioned to 
me have always been of the good kind, as I view them. Like logging in with a 
UI browser and then automating some manual and boring labour with an automated 
tool that can work in the same session. If it would be HTTPS, so be it.

Of course, a browser could also just as well offer a "export cookies in plain 
text" even if it would encrypt them by default and then my "feature" could 
still be served.

>> Do we really need to say that in a protocol spec?
>
> What is wrong with recommending what users assume is true for secure 
> websites?

It was a question. I was looking for more arguments why a spec that documents 
a protocol over the wire should include recommendations on how to store data 
locally.

>> You're apparently referring to 2nd para of sec 6.2. I'm personally fine 
>> with the wording and sentiment of the statements there. again WG would have 
>> to consider any changes.
>
> Above you wrote that you are only documenting the way the web is now. Now 
> you are saying it is ok to insist that browsers replace the set-cookie 
> function with one that will not work with existing websites.

I agree with the current wording of the draft because I think the way cookies 
have currently been handled by APIs etc is a major contributors to the mess 
and problems we have with cookies today.

But I don't think the exact wording of that section is terribly important as 
it is just a suggestion that again doesn't have any specific meaning for the 
actual protocol.

>>> 4) 8.7.  Reliance on DNS. If browsers properly implement per website
>>> self-signed certificates:
>
>> We document the current protocol and practises here. That does not
>> currently include "per website self-signed certificates".
>
> Why does Daniel Veditz of Mozilla/Firefox say it is a standard feature?
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=588704#c46

Handling of self-signed certificates is a standard feature of browsers. So you 
can be aware of possible MITM risks when you connect to a HTTPS site with such 
a cert.

But it doesn't mean that cookies don't rely on DNS. First, many cookies are 
using HTTP and that protocol has no certificates. Then, most browsers allow 
you to accept the self-signed certificate (at least until HTTP Strict 
Transport Security isn't used) and then you get cookies while also relying on 
DNS.

So, there's nothing in the cookie protocol that specificly is using or relying 
on certificates. There are the 'secure' cookies that expect and depend on a 
"secure" connection but I'm quite sure most browsers consider HTTPS secure 
even when the user has blindly accepted a self-signed certificate from a MITM 
(possibly after having been DNS-spoofed).

Cookies as they work today have a few problems. We all know this.

-- 

  / daniel.haxx.se