Re: [TLS] ECH and resumption - what to put in SNI?

[David Benjamin <[e-mail]>]

In addition to needing to send ECH in case the server declines resumption,
we need to keep the ticket under encryption anyway. Without changing how
resumption works, there are a couple of attacks on cleartext tickets:

1. If the tickets from two backend servers are distinguishable from each
other, a cleartext ticket will tell you which backend server it was. This
isn't that implausible as ticket formats often start with a "key name" to
handle ticket rotations (RFC5077 even recommended this), and different
backend servers will use different key names if they don't intentionally
coordinate them.

2. Even if the backend servers have aligned their tickets, an attacker can
still check if the server believes a ticket is resumable with a server name
by sending a non-ECH ClientHello, copying the ticket, making up a fake
binder, and seeing if the server noticed the binder was bad. (Bad binders
are fatal to the connection, but the server only checks a binder once it's
decided to resume with a ticket.) This allows an attacker to confirm a
guess about the server name, up to ticket scope granularity.

Always sending ECH avoids both of these.

This is also the simplest answer and aligns with how we've done everything
else in TLS. The client always offers everything it accepts and allows for
resumption to miss. Resumption may miss for reasons other than key
rotation. Suppose the server changed its version or cipher suite
preferences. That would impact which tickets it accepts. Plus RFC8446
requires that the client resume with the same SNI value, and we have
draft-ietf-tls-cross-sni-resumption as a WG item. Making SNI implicit from
resumption would require revisiting all of that.

I don't follow the concern about clients that can't do fresh DNS queries.
There are two possibilities for any given layer of the system that sets up
TLS:

1. Either this layer knows how to set up TLS, but doesn't know how to
establish connections. Low-level TLS APIs look like this. This layer must
take both the transport connection and ECHConfigList as an external
parameter. Resumption works orthogonally: the layers above run through the
same connection establishment procedure independent of resumption, so you
won't have any more stale of ECHConfigList for resumption as full
handshake. If this layer doesn't know how to establish connections for full
handshakes, it doesn't know how to do it for resumption handshakes either.

2. Or this layer knows how to establish a connection *and* set up TLS.
Maybe this is a higher-level TLS API. Maybe this is the
MakeHTTPSConnection() portion of your HTTP stack. In this case, the layer
is responsible for DNS lookup, evaluating HTTPS/SVCB queries, and using the
ECHConfigList. Resumption is equally orthogonal: whenever you make a
connection, you do the DNS lookup, possibly using a cached record. Then you
check your session cache. Use ECH if you have an ECHConfigList. Offer
resumption if you have a session. Do both if you have both.

In both cases, resumption doesn't affect ECHConfigList availability.

On Fri, Jun 25, 2021 at 10:39 AM Eric Rescorla <[e-mail]> wrote:

>
>
> On Fri, Jun 25, 2021 at 7:21 AM Stephen Farrell <[e-mail]>
> wrote:
>
>>
>> Hiya,
>>
>> If a client established a session to foo.example.com
>> using ECH with a public_name of example.com, what ought
>> the client put in the SNI when resuming?
>>
>> Ignoring ECH, 8446 seems to imply one ought put in
>> foo.example.com [1] but that'd defeat the purpose of
>> ECH.
>>
>
>> If one omits SNI, that would likely be hard to handle
>> for a client-facing server when it tries to route
>> to a good split-mode backend. The same could be true
>> even if example.com is included as the SNI.
>>
>
>> I guess the client could do ECH again, but that'd also
>> be odd, as it'd require asymmetric crypto when resuming
>> (which I guess is a lot of the point of tickets), and
>> depending on ticket ages vs. ECHConfig key rotation
>> times, might cause interesting failures for a library
>> client that can't do fresh DNS queries from within the
>> library (and might never see the TTL of the HTTPS/SVCB
>> RR in any case).
>>
>
> TLS session resumption is soft state, so I believe the correct response
> here is to send ECH. Otherwise, the server cannot properly respond
> if it is not willing to accept the ticket.
>
> The only real alternative here is to have some way for the server
> to indicate that it has forgotten the ticket and the client needs to
> do a full handshake and *now* do ECH. But of course, that's
> not something that's currently specified and isn't really a great
> fit for anything in the protocol, though I guess HRR is closest.
>
> -Ekr
>
>
>> Am I missing something obvious? If not, what's best here?
>> (And we should probably have some text in the draft on
>> this too.)
>>
>> Cheers,
>> S.
>>
>> PS: I guess if the inner and outer ALPNs differed in
>> the original CH, similar issues might arise for a
>> client-facing server, in terms of figuring out the
>> right backend to which the resumed session should be
>> routed, if routing were based on e.g. the inner ALPN.
>>
>>
>>
>>
>> [1] https://datatracker.ietf.org/doc/html/rfc8446#page-57
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>