On Fri, Aug 18, 2017 at 3:46 PM, Daniel Kahn Gillmor
wrote:
> While i think i understand where you're coming from, Tony, i can't help
> but note that this use case is difficult to distinguish from a regime
> that:
>
> (a) wants to forbid anonymous speech, and
>
> (b) wants to censor "unapproved
On Wed, Aug 09, 2017 at 10:54:46PM -0700, Tony Arcieri wrote:
> Consider: a gateway server acting as an external proxy which bridges an
> internal network with the Internet, acting as a forward proxy to
> authenticated clients (either human-driven apps/tools or backend services).
> These sorts of
On Wed 2017-08-09 22:54:46 -0700, Tony Arcieri wrote:
> - The gateway authenticates clients (using e.g. a TLS client certificate)
> and authorizes the outbound hostnames against an ACL. This way we can
> control which clients are allowed to reach which external endpoints.
While i think i understan
On Thu, Aug 10, 2017 at 7:07 PM, Martin Thomson
wrote:
> 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,
So you want CONNECT for TLS? You could have said that.
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.
On 11 August 2017 at 00:03,
On Thu, Aug 10, 2017 at 2:23 AM, Martin Thomson
wrote:
> I'm trying to work out whether there is anything new here. I know
> that browsers implement proxying over HTTPS and CONNECT. Can you
> summarize the ask more succinctly? Because I'm thinking that this is
> a solved problem.
>
> See Secti
I'm trying to work out whether there is anything new here. I know
that browsers implement proxying over HTTPS and CONNECT. Can you
summarize the ask more succinctly? Because I'm thinking that this is
a solved problem.
See Section 8.3 of RFC 7540. We didn't put that there for a lark.
On 10 Aug
As I look at draft-huitema-tls-sni-encryption[1], I really think it's
putting the cart before the horse. I really like the proposed TLS-in-TLS
tunneling mechanism, but I feel it is a generally useful mechanism, and
this draft relegates it to providing a point solution specifically for the
purposes
