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

["Shelby Moore" <[e-mail]>]

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