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,
Eric Rescorla has entered the following ballot position for
draft-ietf-tls-ecdhe-psk-aead-05: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
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
