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

From: "Shelby Moore" <[email-masked]>
Date: Thu, 26 Aug 2010 15:13:56 -0400

>> 1) 4.1.2.6.  The HttpOnly Attribute.  I propose that we need also
>> NoHttp Attribute
>
> No need to. We don't add or change anything in the protocol, we only
> document it in this step!

Please add it to the list of requested features for cookies.

Afaiu, HttpOnly was originally an adhoc feature added by Microsoft, that
was then copied by others. Assuming the new features do not always have to
be created in the market first, then please add my request to your
consideration in what ever WG is appropriate. I notice many of you are
members of multiple WGs, so you know better than I do, where to introduce
this feature request to the record. Please reference my original post from
the archive:

http://www.ietf.org/mail-archive/web/http-state/current/msg00927.html

>> 2) 5.3.  Storage Model. Please recommend that HTTPS cookies be stored
>> encrypted (it can't hurt):
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=588704
>
> This is something that could be added to the security considerations
> section in some fashion, if the WG agrees.

That would be most appreciated.

> Surely it _can_ hurt, for the cases when a second program would
> like to read the cookie storage from a first program.

That is an egregarious security hole. My request was for HTTPS cookies,
not for HTTP cookies.

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

> But if the cookies are meant to be stored on a medium where no others
> should be able to pick up the cookies from,

That is what users have been screaming for 11 years since 1999, why are we
ignoring them for 11 years. See proof at this link:

https://bugzilla.mozilla.org/show_bug.cgi?id=19184

> I figure you could use encryption or other means your system, OS and
> environment allow. Do we really need to say that in a protocol spec?

What is wrong with recommending what users assume is true for secure
websites? Do you realize that most users assume you are not making their
information unencrypted for viruses? They expect that we technical people
are taking care of them. I did not request the use of the word MUST nor
SHOULD. I just asked that we make a recommendation to encrypt if possible,
unless the user has explicitly opted out.

>> 3) 6.2.  Application Programming Interfaces.  Please change "Instead of"
>> to "In addition to".  Never should semantic APIs be a restriction of the
>> general capability. Please!
>
> 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 have no
problem with adding new APIs and see if they become popular, but I do have
BIG problem with insisting that browsers remove the general functionality.
How will I store what I want to store in a cookie, if the semantic
functions provided are insufficient, and you have removed the general
string way?

>> 4) 8.7.  Reliance on DNS. If browsers properly implement per website
>> self-signed certificates:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=588704#c47
>
> The reply to your point (1) applies here too.

> 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

Thanks in advance for your consideration.

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 26 Aug 2010 22:57:29 +0200 (CEST)

On Thu, 26 Aug 2010, Shelby Moore wrote:

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

>> with the wording and sentiment of the statements there. again WG would have 
>> to consider any changes.
>
> 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.

> 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

---

From: "Shelby Moore" <[email-masked]>
Date: Thu, 26 Aug 2010 19:27:40 -0400

Daniel I agree with everything you wrote, except one quibble below, and I
appreciated your reply very much.

> it is just a suggestion that again doesn't have any specific meaning for

Unfortunately, I fear it does aim to kill the general string form of
set-cookie, and I disagree that Almost Better Than Nothing is security.

The problem with bad programming won't go away by removing functionalty.

Fix the other security holes so that users can start to home in on those
bad sites and kill them in the market.  As it is now, there are so many
real security holes that users can't differentiate bad programming from
good programming.

Please don't kill programming, while trying to fix security.  Go after the
real holes, not the Almost Better Than Nothing non-security.

Protocols should say what they mean.  They are very specific documents. 
We don't want to create confusion.  Either say, "deprecate set-cookie for
strings" or change it as I suggested.

Thank you.