On Fri, Jun 25, 2021 at 8:45 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > 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. > The main uses of OpenSSL are (1). TLS stacks typically will be (1) because connection establishment has all kinds of application-specific bits. E.g. connection establishment in general needs to integrate with proxy logic for HTTP CONNECT proxies, and interpreting the HTTPS/SVCB record needs to integrate with Alt-Svc, and deciding between TCP and QUIC. There's some stuff that's partially shaped like (2) with connect BIOs and such, but most applications don't use it. I've not thought very hard about how an HTTPS/SVCB embedding of that API would look like. But either way, the point about resumption being orthogonal stands. David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
