On Wed, Oct 04, 2017 at 05:03:20PM -0400, Patrick McManus wrote: > On Wed, Oct 4, 2017 at 3:15 PM, Toerless Eckert <tte@xxxxxxxxx> wrote: > > > On Tue, Oct 03, 2017 at 08:43:37PM -0400, Patrick McManus wrote: > > ... > > > Given all of that, you're much better building a session mechanism at the > > > application level.. as ugly as cookies are, they are the typically way to > > > do that in a consistent manner in both h1 and h2. That's going to be way > > > more robust (and performant) in the long run. > > > > AFAIK, even secure cookies depend on trust in the server certificate for > > the > > TLS connection. And AFAIK common practices like cert pinning still have > > day 0 gaps. BRSKI effectively provides a method to gain trust into a > > server cert without those workarounds. Via the first HTTP transaction. > > > > I'm not totally sure we're speaking the same language but I think you're > misunderstanding the suggestion. Which part of cookie did i misunderstand ? ;-P > Use the trust you establish with your > first transaction to build the cypto-verifiable session key that subsequent > transactions can carry as proof they were serialized (i.e. an application > layer session identifier). It will be much more robust than trying to > figure out what the transport properties of what HTTP treats as independent > transactions are (both in future, and I suspect in some corner cases > present and past). Lets see first if we can identify actual dangers. If i blindly started to mistrust any properties of HTTPS, i'd have to start duplicating it. Cheers Toerless