Re: [quicwg/base-drafts] How to reject a connection attempt (#3690)

[mjoras <[e-mail]>]

> Having that said, I'd hope that we can agree on one principle: QUIC cannot respect unauthenticated information any more than TLS over TCP does. Otherwise, QUIC becomes more prone to MITM attacks that TLS over TCP is - a disobedience to our charter.

@kazuho No introduction of error codes can possibly make QUIC more prone to this than TCP + TLS. A TCP connection can be completely interrupted at any time with an unauthenticated RST. In that sense I don't think it's possible to make QUIC more prone to MITM attacks than TCP + TLS, since at the very least we only have a small window for the similar MITM interruption.

> To function reliably on the internet a client has to use heuristics and unauthenticated information in order to provide a good user experience and not overwhelm server resources.

> > That might be true, but our experience with TLS over TCP is that we do not need an error code for the purpose.

It's not a fair comparison, as TCP does not have an opportunity to fallback to anything. You posit that we have to view the QUIC specification in isolation from the existence TCP or any "happy eyeballs" mechanism, and I don't totally disagree but I don't think it follows we should make decision _ignoring_ the realities of deploying QUIC on the Internet. That reality is, today, that QUIC will not work 100%, whereas we expect TCP to function. If we can add things to the specification which aid in a seamless coexistence of QUIC and alternatives, why would we not?

> Am I correct to understand that the reason you are advocating for having more error codes is to allow a server to control the behavior of client for future connection attempts? Assuming that is the case, I'd oppose to having such error codes regardless of how we would describe them. Because IMO that is effectively about making QUIC more prone to attacks than TLS over TCP is.

I don't think I fully understand your point here. You asserted that the client "should refrain from using an unauthenticated signal for determining what to do with future connection attempts". I maintain that this is fantastical. The client has to do _something_ with future connection attempts whether we prescribe a behavior or not, and as such it is abundantly useful to be able to influence, if not dictate, the behavior of clients with more explicit signals from the server.

As it is I am fine with leaving this discussion with the generic CONNECTION_REFUSED and calling it a day, but I think there's value in discussing the real-world considerations here, which was @marten-seemann's original motivation.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3690#issuecomment-637209040