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

[Kazuho Oku <[e-mail]>]

@mjoras I'd emphasize that the specification does not talk about happy eyeballing. We should concentrate on discussing what to do when only QUIC is being used.

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.

>  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.

> As has been said already, we already have 100% reliable and trivially implementable way to interrupt the handshake in v1 with version negotiation. Having an additional signal which is more explicit can only help clients making new connection decisions.

FWIW, you do not need a version negotiation packet. Per my understanding, any server can send a private error code. Or a reason phrase explaining things.

> We don't necessarily have to prescribe what the client does, but we can say why a server may issue certain errors during the handshake.

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.

-- 
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-634285890