[TLS] checking a bit of ECH behaviour

[Stephen Farrell]

Hiya,

I'm processing maintainer comments as I try get ECH code upstreamed
and wanna check a thing. Let's say the following happens:

1. Client send CH including real ECH attempt
2. Server responds with HRR including good ECH acceptance signal
3. Client sends 2nd-CH with new group and another ECH attempt
4. Server responds with SH without good ECH signal and retry-configs

In the above the server is behaving oddly, managing to successfully
decrypt ECH in the 1st round but failing to do that in the 2nd. But
I guess that could happen even if it shouldn't.

After 4, I think a client library should just make the retry-configs
available to the calling application as usual. Does anyone disagree?

I also think the ECH draft doesn't explicitly say to do that.

That might I guess mean the retry-configs might be the same as the
ECHConfig that the client used at step 1, so there's a potential
loop if it all keeps happening, but since using the retry-configs
(or not) is a client application decision, that's out of scope for
a TLS library.

I don't think any change to the ECH draft is required to handle
this, but if someone wanted to add a sentence that'd be ok too.

Thanks and apologies if I'm missing where this was handled in the
draft or discussed previously,
Cheers,
S.



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Implicit ECH Config for TLS 1.3 – addressing public_name fingerprinting

[Kazuho Oku]

Hello Nick, folks,

I only had the chance to look at the draft and the presentation during
IETF, but I actually like this idea.

To address the concern of outer SNI becoming an observation vector, the
presentation suggested that clients should use "any choice of valid DNS
names."

But as some pointed out, the problem of choosing something valid remains.
Some clients might pick only within a certain suffix. Different clients
might choose them differently.

So, instead, I wonder if we could just say that all ECH clients should use
one value. Using one is simpler, and provides the guarantee that nothing
leaks other than the fact that ECH is used.

And to take another step forward, we can even choose the most popular
hostname around the world to be that one outer SNI. By doing so, we can
hide the ECH traffic being small during the adoption period.

I do understand that the content network operators do not want to abuse the
hostnames that their customers own for protecting other customers.

But what I am saying here is that we can shift the responsibility of
choosing the outer SNI from the content network operators to the clients.
If clients start sending whatever outer SNI that they like, content network
operators have no choice but to ignore that field.


2025年2月26日(水) 14:16 Nick Sullivan :

> Hi everyone,
>
> I’ve put together a draft, “Implicit ECH Configuration for TLS 1.3” (
> https://www.ietf.org/archive/id/draft-sullivan-tls-implicit-ech-00.html),
> as a potential starting point for improving ECH’s “do not stick out”
> compliance. Global deployments of ECH have become biased because a single
> public_name dominates most ECH connections, making it a prime target for
> fingerprinting (see https://github.com/net4people/bbs/issues/417). As
> discussed on the TLS WG mailing list (see
> https://mailarchive.ietf.org/arch/msg/tls/4rq4sZzpI9rjYgDLJ2IO-vG9DRw/),
> the outer SNI remains the primary identifier that enables on-path
> adversaries to identify ECH traffic.
>
> To mitigate these linkability risks, various past proposals were
> considered. One idea was to randomize or override the outer SNI rather than
> always using the provided public_name. For example, Stephen Farrell
> suggested allowing clients to use an arbitrary or blank outer SNI (for
> certain use cases like censorship circumvention). This would, in theory,
> make the outer handshake less predictable, increasing traffic diversity
> across ECH connections. However, others in the WG (e.g. Chris Wood)
> cautioned that relaxing this requirement essentially reintroduces domain
> fronting, a side-effect the group was wary of.
>
> The consensus was that fallback reliability and simplicity favored
> sticking with the public_name in SNI. See Github discussions:
> https://github.com/tlswg/draft-ietf-tls-esni/issues/396
> 
> .
>
> Relatedly, early drafts used an 8-byte config_id, but as documented in
> discussions around 2020-2021, it was shortened to one byte to reduce its
> uniqueness and tracking potential—a change that was well received by
> privacy advocates yet noted by implementers as complicating the deployment
> complexity for multi-key scenarios, though not enough to hinder deployment.
>
> Implicit ECH Configuration, introduced in
> draft-sullivan-tls-implicit-ech-00, builds on this prior work to propose a
> mode of ECH that minimizes explicit signaling of the server’s identity.
> This draft introduces an optional “implicit” mode via a new extension in
> ECHConfigContents. When this extension is present, clients MAY choose any
> valid outer SNI and a randomized config_id instead of relying on a
> potentially globally dominant public_name. Client-facing servers, in turn,
> MUST perform uniform trial decryption to ensure that every handshake is
> processed identically, regardless of whether a valid or a phony config_id
> or outer SNI is provided.
>
> This approach enables clients to adopt custom strategies for maintaining
> broad reachability, ensuring that a single public_name does not become a
> reliable way for external observers to distinguish ECH from ECH GREASE at
> scale. It is also useful for improving privacy when client-facing servers
> support only one or a small number of domains, as it enables clients to
> choose the outer SNI such that it is not merely a direct stand-in for the
> inner name.
>
> Importantly, I don’t believe this approach reintroduces domain fronting.
> It’s not possible to use implicit configuration ECH to connect to one site
> on a server and then trick that server into serving HTTP responses for a
> second, different site when the TLS certificate used to establish the
> connection is not authoritative for that second site – the essential thing
> that distinguishes domain fronting from other techniques. Implicit mode
> effectively relegates the outer SNI to a mostly symbolic role for

[TLS] Mike Bishop's No Objection on draft-ietf-tls-tls12-frozen-06: (with COMMENT)

[Mike Bishop via Datatracker]

Mike Bishop has entered the following ballot position for
draft-ietf-tls-tls12-frozen-06: 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 to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/



--
COMMENT:
--

The registry note "Any entry [...] makes no requirement on DTLS" does not seem
correct. Consider rewording this to indicate that the *notation* does not
impact DTLS, or consider adding separate explicit columns for TLS and DTLS
version restrictions.



___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [Gen-art] Genart last call review of draft-ietf-tls-tls12-frozen-05

[Salz, Rich]

Given that this document, once published as an RFC, places normative
restrictions on IETF work, it seems odd to list it as "Informational"?
Wouldn't BCP be a better status for it?

During the long bleak winter where this review sat answered :), we did change 
it to STD.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: checking a bit of ECH behaviour

[Stephen Farrell]

Hiya,

On 22/03/2025 23:20, David Benjamin wrote:


To that end, the proposed protocol change wouldn't work in the first place.


It wasn't a proposed change, I was just checking if some corner-case
code was right or wrong, and as you point out above, it's wrong, or
rather, even if that code copies the proposed retry-configs, the h/s
will fail as the sides are using different transcripts.

> I remember we discussed all this

I, clearly, did not:-)

Thanks,
S.



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org