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

[Stephen Farrell <[e-mail]>]

So I guess we're landing on "if the client got a ticket via
a session that successfully used ECH, it MUST send a fresh
ECH when using that ticket"? That's ok I guess, but maybe
some more detail is needed...

On 25/06/2021 17:01, David Benjamin wrote:
> 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.

I'm not sure yet that OpenSSL matches either 1 or 2, (I've
only done some basic tests) but in any case it seems like
the client could have a ticket cached but get an entirely
different SVCB RR with a different public_name the 2nd time
so I'm not sure that things work well in all cases.

S.