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