Marten Seemann

The Go standard library implementation doesn't allow us to modify the information that gets [stored in the session ticket](https://github.com/golang/go/blob/980a57a84b932b43fc2d3ab699f7c235472009ab/src/crypto/tls/handshake_server_tls13.go#L741-L750) (there is a proposal to change that, but it seems to...

See https://github.com/golang/go/issues/31641.

Thank you writing this up @yusefnapora. Not sure if this is the right repo to have this discussion, it seems like the API we're defining applies to all transports. Maybe...

> It seems like data sent through an EarlySecureConn could potentially be sent either before or after the handshake completes, depending on the timing. [...] It just shifts my mental...

Not familiar with the Noise code at all, but TLS standard library uses the `KeyLogWriter` in the [tls.Config](https://golang.org/pkg/crypto/tls/#Config).

## Dealing with 0-RTT Rejection There are 2 options for dealing with 0-RTT rejection that come to mind: 1. Let the application deal with it, by returning an `ErrZeroRTTRefused` whenever...

The question we need to answer is what most applications would want? Would they want to write different data if 0-RTT is rejected, or will (almost) every application just retransmit...

> but 0-RTT is more than that: it's dropping a security guarantee. That's why I suggested an opt-in. If an application doesn't change anything, it won't get access to a...

> 1. Store session keys in the peerstore. Yes. > 2. Make sure to remove them when they're used (to prevent replay). quic-go (or rather, [qtls](https://github.com/marten-seemann/qtls), quic-go's TLS library) does...

> > Unfortunately, TLS session tickets are only sent from the server to the client. > > Yes, but we can generate and send one back in a side-channel (new...