On Thu, Aug 10, 2017 at 7:07 PM, Martin Thomson <martin.thom...@gmail.com>

> What makes you think that the implementation story here would be any
> different?  I'm not trying to destroy your idea, which seems fine on
> face value, but just trying to understanding the value proposition
> better.

As I said earlier, the implementation story is the same (or extremely
similar), but it's looking at the problem from a different perspective:

What I think is particularly interesting about this use case in the context
> of the SNI encryption discussion is it is in fact almost entirely the same
> problem from a technical perspective. Where it differs is largely in the
> framing of the problem: instead of using the gateway to reach a hidden host
> from the Internet, we are using the gateway to talk to the Internet from an
> internal network which needs to go through a proxy host to reach the
> Internet.

I did also list a few things I think are tangibly different:

There are a few additional things which are different between the cases
> beyond some of what I've just mentioned. Ideally the client verifies the
> gateway's server cert against an internal-only CA bundle, then verifies the
> tunneled destination host against a public CA bundle. We might want a
> client to present an internal client certificate to the gateway, but
> present no cert/a different cert to the destination host. That said, aside
> from minutia like that, the machinery seems largely the same.

Support for using different CA bundles for the gateway versus the
destination host seems important in this use case, IMO.
Also: support for sending different certs to the gateway versus the
destination host.

While these are ultimately just implementation details, I think they're
worth at least considering when such a draft is being authored.

Tony Arcieri
TLS mailing list

Reply via email to