Signaling TLS handshake failure

[martinthomson]

This needs to be written down. I think that the best outcome would be to include BOTH a TLS alert and a QUIC error code (in a CONNECTION_CLOSE frame).

[ianswett]

I don't know if there's an open issue for this, but I think the only frames we want to send unencrypted are stream frames for stream 1 and ack frames. Those we believe are necessary and even ack frames have special rules, as we've discussed.

We could send an unencrypted connection close frame, but I'm having a hard time seeing cases when a TLS alert wouldn't be better. And in other cases, a public reset is sufficient.

[RyanTheOptimist]

CONNECTION_CLOSE should definitely be allowed. There are any number of insane things a client could do which would cause the server to want to tear down the connection. When this happens, it's very valuable for the client to see the error code from the server.

[martinthomson]

@ianswett, there's lots of text on the point of what can be unencrypted, and some issues on the finer points (like the issue around acknowledgments).

As you say, the TLS alert is going to be useful for diagnosis if nothing else, but if we are to maintain our layering, we need a CONNECTION_CLOSE as well. Luckily, they can both be carried in a single packet.

[ianswett]

I may be missing it, but when I skimmed and searched in the transport draft, I couldn't find anywhere it said what frame types may be sent without encryption.

I'm happy to have both TLS alerts and connection closes if they're useful. Ryan reminded me there have been some cases when unencrypted connection close errors were able to provide valuable insight to debug an issue.

[martinthomson]

The TLS draft has all that text. Currently.