Don't haphazardly suggest retrying over TCP

[martinthomson]

The application SHOULD attempt to use TLS over TCP instead.

(This is in the context of finding that the MTU is too small.)

The text includes a very specific recommendation to use TLS over TCP for one particular case. This is unwise for two reasons:

1. we don't know if all protocols that build on QUIC will have a TCP over TLS option available to them; DNS over QUIC might be an example of where TLS over TCP is an inadvisable fallback option
2. we should rely on a generic error handling section that includes generic advice about things like falling back to a backup protocol

Marked as editorial, I hope that's not controversial.

[RyanTheOptimist]

Good point!

[hardie]

I understand why we don't want to recommend a specific fallback, but there's an implication here we may want to keep. If you want to use QUIC with a fallback, that fallback should have roughly equivalent security properties or blocking QUIC is a downgrade attack. So the DNS example might be falling back to DNS over DTLS, but it would not be falling back to plaintext UDP. That may be better expressed in a document about which protocols could theoretically adopt QUIC than here, but I don't want to lose it entirely.

Note that I'm assuming here silent fallback, where the user is never told which protocols are in use under the hood. I'm sure there are other choices for when the user is looped in, but I don't think those are QUIC's business.

[martinthomson]

Good points Ted. I wonder whether DNS over QUIC would be done opportunistically or not. That changes the calculations too. No one currently has any real expectation that DNS is confidential (/me makes a sad face).

[mirjak]

I think this is input for the applicability statement. It's partly in section 2.1 of draft-kuehlewind-quic-appman but only talking about fallback to TLS/TCP. We didn't consider the DTLS/UDP case; should add that.