[comex]

You can add a concept of session without removing cookies, which are trivial to keep supporting since, as I mentioned, browsers will have to support cookies for legacy sites for a long time anyway.

I doubt the security argument amounts to much, considering that there are few sites with cookie-based vulnerabilities, it's long been trivially easy ($_SESSION in PHP) for any site to use identifiers as cookies, and many of the sites that are vulnerable are the kind of old-fashioned things that will never be upgraded anyway.

[jasonwatkinspdx]

Once you have a concept of a session unique nonce, cookies are needless. Browsers can implement a locally encrypted resumption store where the user entered entropy never touches the network to resume a session on the same machine. Resuming a session on a new machine could use 2 factor auth with fallback one time capabilities. That's big, doubly so given the clear historical trends in users ability to memorize entropy and the likelihood of hashed password database disclosure.

What you need to understand, is that we can get rid of cookies, live in a more secure world, and give up nothing. The only thing holding us back is unwillingness to understand the underlying issues and fear that we stand to lose something by advocating change.

On top of that, by standardizing on a nonce we avoid all cookie request overhead larger than the nonce, which is not trivial. Every mandatory request byte we save under MTU is huge.

[comex]

There is no difference between browsers implementing a locally encrypted resumption store for a nonce and for cookies (since again, most sites where security is important already use cookies purely as identifiers); nor does it affect whether sites will start requiring two factor for all logins. The two systems are equivalent except that one is simpler, but the (small amount of) complexity of cookies is not what's blocking these types of security measures.

I'm not saying additional login security isn't a good idea (although since local cookies tend to be compromised by malware running on the machine rather than offline attacks, it may not be that useful to encrypt them), and I'm not saying that avoiding cookies isn't a good idea, because cookies do tend to get bloated. But tying the two proposals together is unhelpful to both, because they're essentially orthogonal.

As for avoiding cookie request overhead, that is again something you can do by adding a standard nonce without actually removing the old mechanism; sites that want to be fast or have a standardized way to interact with HTTP routers, and most sites that use web frameworks, as the frameworks get updated, will use the new one. The only way removing cookies would help is if servers started translating cookies for legacy applications automatically, but I don't see that becoming prevalent because of document.cookie and related concerns.

edit: and again, breaking backwards compatibility is a great way to slow HTTP/2 adoption, not that it really matters unless it brings TLS to all sites along with it (but that's another story...)

[jasonwatkinspdx]

They are different because a server suggested resumable session nonce requires no form based authentication. User entered entropy never hits the wire. I do not know how to emphasize this point more strongly. Please read the research on trends in brute force and timing attacks vs human capacity for entropy memorization.

Evidence is clear: The majority of sites do not handle cookies securely. They do not handle user submitted entropy securely. Virtually no one supports 2 factor authorization (props to google on this point).

The scheme I am suggesting and the status quo are not equivalent as you suggest. I do agree that they are orthogonal, except at the point where we decide upon a standard.

I take it as a given that the status quo is unacceptable. If you disagree there's not much for us to discuss.

What I'd like to see is http/2 be a fresh design that is unwilling to sacrifice security. We can always assume http/1.1 or failback to it under negotiation. Because of that, there is no reason to burden a new standard with backwards comparability. Among the SPDY community you see this same perspective, often suggested as a tick/tock strategy where when version n+2 goes online version n+1 becomes backport only support and version n is abandoned.

[comex]

Server suggested resumable session nonce is just a cookie. If you want the user to be able to put in a password without sending it in plaintext to the server (i.e. make HTTP authentication actually work properly) that would be really really great but, I think, also a different proposal.

Well... I don't think it's worth drawing a line in the sand here, because the speed and, should TLS-always-on make it in, security benefits of the existing protocol are significant enough that everyone should be able to use them without rewriting their authentication system. But I'd certainly be for a comprehensive proposal for a new authentication system; it would probably be significantly cleaner than BrowserID.