Discuss how TLS `ClientConfig` should be passed around about quinn

[Ralith]

A client may want to communicate with different types of servers via different protocols without allocating redundant endpoints, so per-connection ALPN is necessary as a baseline. On review I don't actually see anything else in ClientConfig that seems obviously useful (and rustls is mistakenly using String for ALPN IDs there too) so maybe it would be better to define our own API just for that.

[djc]

And abstract over cloning the underlying ClientConfig and mutating the clone? Maybe we should open an issue in rustls to see what they think about changing the API around this? (Something like ClientSession::with_alpn_protocols(..) that overrides the Configs defaults.)

[Ralith]

Another per-connection variable could be certificate verification overrides, which we'll want sooner or later (not just for untrusted connections, but also for unconventional verification schemes like Perspectives).

Maybe we should open an issue in rustls to see what they think about changing the API around this?

Is there that much room for improvement over duplicate config objects? They're not that big, are they?

[djc]

Is there that much room for improvement over duplicate config objects? They're not that big, are they?

The documentation says:

Making one of these can be expensive, and should be once per process rather than once per connection.

It's not quite clear whether that means cloning would also be affected.

I really don't think we should be optimizing for per-connection certificate verification overrides until a concrete use case comes up.

[Ralith]

It's not quite clear whether that means cloning would also be affected.

The definition is just a few small Vecs and some Arcs; seems likely that allocating a new connection's state would be much more expensive.

I really don't think we should be optimizing for per-connection certificate verification overrides until a concrete use case comes up.

I don't think this is such a weird case. Any application that wants to talk to both unauthenticated hosts (e.g. P2P peers, back-end services on a private network) and conventionally-authenticated ones (e.g. external web services) at the same time calls for that type of variation. Not something we need ASAP, for sure, but it's useful enough to motivate a general notion of per-connection configuration.

[djc]

I clarified the method name; I think adding CAs (rather than setting one) would mostly cover that?

[Ralith]

For P2P, TOFU, or sidechannel-based verification systems, a CA wouldn't accomplish anything. Sometimes you just want to talk to someone that hasn't been vouched for in advance by a central authority.

[djc]

CA in this context doesn't mean something in Mozilla's root store, but just the certificate chain root.

[Ralith]

I got that; the problem is that there is no trust authority in those systems, so the only way to have a CA would to to distribute its keys with the software, which would make it meaningless--just an elaborate and confusing workaround for an API limitation. Even if you were okay with that sort of hacky work around, you absolutely wouldn't want such a CA to globally apply to outgoing connections from the same application to services that can be verified by traditional CAs.

[Ralith]

Another complication is that some rustls ClientConfigs are illegal for QUIC--for example, ones that permit TLS versions other than 1.3. If the ClientConfig object is to be exposed directly, we'll want to take care to document these restrictions and place appropriate asserts.

[djc]

Other trickiness in the EndpointBuilder API that might be relevant: it currently allows a reset of the Config with the config() method (from the Config::default() it initializes with), but some of the methods also change the Config, so if called in some orders, some stuff gets thrown away.

Also sticky: what if Quinn is used in a HTTP context in a stack that can do either QUIC, H2 or 1.1, we may want to share the TLS configs for both (at least some parts).

[icefoxen]

I definitely would like the ability to connect to untrusted hosts, since I'm using this crate for a P2P network experiment. Not much point in having a CA and chain of trust in such a situation.

Right now I can do that just by having the CA certificate built into the program, but as Ralith says it's essentially useless if not worse than useless. It also makes unit testing a little less convenient than it could be, though that's not as big an idea.

For the EndpointBuilder thing, I dunno if it's applicable but I handle this in ggez just by documenting the behavior and making it transparent what structs the builder is made out of. The jury is still out on whether that is at all troublesome though.

[djc]

I think this has mostly settled down now, and can be closed?

[Ralith]

Good call.