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.
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
