W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2015

Re: Comments about draft-ietf-httpbis-http2-16 : Connection reuse

From: Ryan Hamilton <rch@google.com>
Date: Fri, 2 Jan 2015 09:27:03 -0800
Message-ID: <CAJ_4DfRntr7GsoWva503b7TdP1CDdwyMbve==nWJh9kbaMLoWA@mail.gmail.com>
To: Aeris <aeris@imirhil.fr>
Cc: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, Patrick McManus <pmcmanus@mozilla.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
The requirement to reuse a TLS connection is that the cert is "valid". This
does not simply mean that the cert contains a matching Subject-Alt-Name, it
means that *all* the validity checks are satisfied. For a User-Agent that
supports TLSA it must check TLSA (Chrome does not support TLSA so I'm not
familiar with what they are). In the case of Public Key Pinning, the must
check that the pins are satisfied. Chrome does support pinning and so if
you look at the code which checks to see if an existing connection can be
used for a new hostname, you'll see that it explicitly verifies the pins:

https://code.google.com/p/chromium/codesearch#chromium/src/net/spdy/spdy_session.cc&sq=package:chromium&l=568&rcl=1420152226

I think that the requirement in 9.1.1 is sufficient.

On Fri, Jan 2, 2015 at 7:21 AM, Aeris <aeris@imirhil.fr> wrote:

> > Err, why isn't just validating the current certificate against fetched
> TLSA
> > records and then opening a new channel if that fails (DNS caches should
> be
> > hot) sufficient?
>
> Oops. Yes, will be good this way.
>
> > HPKP is nastier, especially in the non-pinned case.
>
> Yep, it’s the worst case. Need new channel in all case, even if not HPKP at
> the end.
> Same for proto/ciphers check.
>
> > Another interaction between connection reuse and HPKP: Potentially
> having to
> > deal with server trying to pin the reused connections (foo.example
> pinning
> > bar.example, when foo.example and bar.example share a connection).
>
> Could be tricky…
>
> It shows than connection reusage is not trivial at all, and suffer of very
> deep
> implication on TLS ecosystem and overall security.
> Even if fully specified, the code necessary to handle all cases correctly
> will
> just be a bunch of spaghetti and depends of hundred of parameters (some
> totally external to HTTP2 stack or to browser built-in features), with no
> insurance of better perf or (at least) same security compare to no reusage
> at
> all.
>
> --
> Aeris
>
> Protégez votre vie privée, chiffrez vos communications
> GPG : EFB74277 ECE4E222
> OTR : 5769616D 2D3DAC72
> https://café-vie-privée.fr/ <https://xn--caf-vie-prive-dhbj.fr/>
>
Received on Friday, 2 January 2015 17:27:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:42 UTC