W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: Expectations for TLS session reuse

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 23 Dec 2016 09:30:48 +1100
Message-ID: <CABkgnnUf8xG7espU5DsQiQg7944F9Nrhz0d91Lv27=V3NVY9oA@mail.gmail.com>
To: Richard Bradbury <richard.bradbury@rd.bbc.co.uk>
Cc: Lucas Pardue <Lucas.Pardue@bbc.co.uk>, Mike Bishop <Michael.Bishop@microsoft.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Patrick McManus <mcmanus@ducksong.com>, Eric Rescorla <ekr@rtfm.com>
On 23 Dec 2016 5:04 AM, "Richard Bradbury" <richard.bradbury@rd.bbc.co.uk>
wrote:

Hmm... The statement in the above quotation seems inconclusive to me.
Surely a client could verify the server's identity simply by checking that
the target authority appears in the server's certificate (and that the
certificate is valid too, of course...). Wouldn't that satisfy the security
consideration on establishing authority described in section 9.1?

Yes[1], if the cert is good and the name is right, that is enough.

Except... We still require that the IP address matches.  But only for
coalescing:

> For TCP connections without TLS, this depends on the host having resolved
to the same IP address.
>
> For https resources, connection reuse additionally depends on having a
certificate that is valid for the host in the URI.

It seems like the requirements for the initial connection are the only ones
that are ambiguous :)  ah the joys of dealing with specs.

Maybe I need to do a writeup. That isn't going to happen soon though. Keep
up the good work, and maybe you can write this up.

[1] The part that you might have been missing is how the valid certificate
is linked to a trust anchor.  That is where is gets much, much more
complicated.  (You might have meant to include that by saying  "valid", but
I wanted to be explicit.)
Received on Thursday, 22 December 2016 22:31:16 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 22 December 2016 22:31:34 UTC