Benjamin Saunders

A couple examples: [RFC 9001 §6](https://www.rfc-editor.org/rfc/rfc9001.html#name-key-update): > Endpoints MUST treat the receipt of a TLS KeyUpdate message as a connection error of type 0x010a, equivalent to a fatal TLS alert...

On review I believe you're correct. Relevant text from [RFC 9000 §11](https://www.rfc-editor.org/rfc/rfc9000#name-error-handling): > Where this specification identifies error conditions, it also identifies the error code that is used; though these...

As a hacky work-around, you can make up whatever hostname you want, so long as what the client supplies to `connect` matches the certificate.

Having these available early is required to support 0.5-RTT communication from the server, which is currently implemented in Quinn.

That's for the server, to be clear. For the client, we require immediate access to the transport parameters saved from the previous connection in the session cache for 0-RTT to...

Yeah, they shouldn't be put into the cache by rustls unless the handshake succeeded. I don't think they can even be delivered before then, though I'm less of an expert...

I don't have plans to work on this in the near future. > Then the public accessor from the would only be able to access them if the current state...

That sounds reasonable for the client. For the server (0.5-RTT) I think we actually need the just-transmitted parameters, though.

§7.4.1 discusses the transport parameters sent by the server to the client: > To enable 0-RTT, endpoints store the values of the **server** transport parameters with any session tickets it...

> Discard any with an ID that isn't that aren't explicitly known to be relevant and safe for 0-RTT (allowlist approach; new 0-RTT transport parameters would require updating Rustls to...