Good day,
The ECH draft describes a method for securely disabling ECH - at the cost
of an extra round trip. Is there a client and server implementation that
supports this functionality already - securely disabling ECH?
SB
___
TLS mailing list
TLS@ietf.o
gt; new transport connection and ECH disabled."
>
> -Ekr
>
>
>
>> On Mon, Sep 19, 2022 at 11:20 AM Safe Browsing
>> wrote:
>> Good day,
>>
>> The ECH draft describes a method for securely disabling ECH - at the cost of
>> an extr
t 9:35 AM, Safe Browsing wrote:
>
> Yes, that is it. Via section 8.2:
>
> 8.2. Middleboxes
>
> When connecting through a TLS-terminating proxy that does not support this
> extension, [RFC8446], Section 9.3 requires the proxy still act as a
> conforming TLS client and se
Hi Rich and Eric,
Thanks for the replies.
Let me add to the picture:
Client <-> *Middlebox* <-> TLS terminating <-> Desired Origin
Or to put it in the TLS ECH draft terminology (split mode topology) - as
per my understanding - :
Client <-> *Middlebox* <-> Client-facing server <-> Backend serve
Hi Rich,
When I say “authoritative”, I mean it in the true TLS sense, in the way that I
believe the ECH draft also suggests and requires.
In other words, the middlebox serves a cert to the client that is
cryptographically valid for the said public name of the client facing server.
How can that
Thank you Dennis. Will give it a try.
Best regards,
SB
On Mon, Oct 10, 2022 at 11:07 AM Dennis Jackson wrote:
> You and "SB" are in agreement. There is a middlebox terminating the TLS
> connection with a cert chain signed by a root which is also installed on
> the client. The middlebox in turn
H.
>
> -Ekr
>
>
> On Fri, Oct 7, 2022 at 8:40 PM Safe Browsing
> wrote:
>> Hi Rich,
>>
>> When I say “authoritative”, I mean it in the true TLS sense, in the way that
>> I believe the ECH draft also suggests and requires.
>>
>>
he server, as opposed to the
"retry_config" retry method with ECH still enabled - they are of course
very different retry mechanisms.
On Wed, Oct 19, 2022 at 1:44 AM Nick Harper wrote:
>
>
> On Tue, Oct 18, 2022 at 8:56 PM Safe Browsing
> wrote:
>
>> The draft
lematic.
>
>
>
> If I read your email correctly then I believe that’s what you are
> suggesting. I hope I am missing something.
>
>
>
> Ciao
>
> Hannes
>
>
>
> *From:* TLS *On Behalf Of * Safe Browsing
> *Sent:* Wednesday, October 19, 2022 4:56
> Giving someone, other than those managing the endpoints, the ability to
> disable a security feature like ECH is problematic.
>
>
>
> If I read your email correctly then I believe that’s what you are
> suggesting. I hope I am missing something.
>
>
>
> Ciao
>
>
led "transparent" proxies relie on lies. The price of lies is of
> course brittleness. Configured proxies could be made robust.
>
> -- Christian Huitema
>
> On Oct 19, 2022, at 5:55 PM, Safe Browsing
> wrote:
>
>
> Hi Christian,
>
> For transparent proxies, n
ated. Clients
> that want wide interoperability will implement retry without ECH whether or
> not the spec says it's a MUST, and likewise clients that will only connect
> if ECH is used will choose to not implement the fallback regardless of what
> the spec says.
>
> On Wed, Oct
Certainly, within the umbrella of "Network Security", privacy is a
category. ECH falls into that category.
As with many things in life there is also a trade-off that ECH brings
along. More privacy, at possibly less "Network Security" (not a less secure
TLS connection), as noted in some of the othe
13 matches
Mail list logo
