Replace CONNECTION_CLOSE with Public Reset

[martinthomson]

@martinduke suggested that we might remove CONNECTION_CLOSE in favour of using a Public Reset packet. That would require that the error code be made public knowledge.

I can see a few advantages for a middlebox, primary of these being a clear signal that a connection is done (though that would not be something that could be strongly authenticated). It would also simplify state on servers that decide to terminate a connection: they only have to keep whatever information they need to generate a Public Reset, which is a single piece of global state.

The downside is the insights that the error code give into the otherwise confidential operations of the protocol (we'd likely want to tighten the level of detail in error codes). Also, it means that a server that wants to permit retries would have to send two packets: a GOAWAY packet in addition to the Public Reset.

[ianswett]

I don't understand "Also, it means that a server that wants to permit retries would have to send two packets: a GOAWAY packet in addition to the Public Reset."

Today a server has to send a GOAWAY and a CONNECTION_CLOSE, so it seems equivalent?

But yes, I think the only concern is that the error code could be a privacy leak of some sort.

[martinthomson]

GOAWAY and CONNECTION_CLOSE can be sent in the same packet. Public Reset can't occupy the same packet as GOAWAY.

[mirjak]

You could have a limited set of short error codes and a longer reasoning phase that is encrypted and can only be send if the server still has encryption context.

[mcmanus]

Under some circumstances the endpoint needs a clear indication that the connection is done beyond GOAWAY. So let's send that authenticated so it can be trusted. That's generally a great property of QUIC, I don't think we should throw it away here - we should be removing PUBLIC_RESET uses cases wherever possible because they have poor security properties.

[martinduke]

we should be removing PUBLIC_RESET uses cases wherever possible because they have poor security properties.

I don't see what this achieves. We are not going to eliminate PUBLIC_RESET, so it will always be available for attackers who want to break connections. The protocol is only as strong as the PUBLIC_RESET authentication, so imposing additional security on a subset of termination messages achieves nothing.

This wouldn't be true if we declared different behavior on receipt of PUBLIC_RESET: for instance, the receiver could keep state for some amount of time, in case legitimate packets arrived after a spoofed reset. But in the absence of such a mechanism, CONNECTION_CLOSE achieves nothing.

[mcmanus]

On Thu, Mar 2, 2017 at 12:13 PM, martinduke ***@***.***> wrote: We are not going to eliminate PUBLIC_RESET,

I don't take that as a given (its possible though). 1] in the absence of PR, things devolve to (high latency) timeouts. The timeout paths are necessary anyhow as PR might not be delivered, though obviously high latency is painful. 2] the primary use case for PR is "endpoint lost trust state and can't send connection close". But you can trivially build something better than public here (but worse than per connection).. handwave a public 'call me back with a new connection and your connection ID and we'll form a new connection to tell you the old one is lost' - at least that's verifiable as coming from the right origin. 3] the other use case for PR is network signaling. Overloading that with reset doesn't make a lot of sense to me - the right reaction to a middlebox that indicates a path is no longer usable might very well be to try and route around the middlebox - not accept the reset. Overloading CONNECTION_CLOSE with PUBLIC_RESET means the endpoint can't make that distinction.

[martinduke]

(1) and (2): If we decide to eliminate PUBLIC_RESET, then that obviously has implications here. I had detected any sentiment for this to date.

(3) I agree that network signaling is the other use case, but in the opposite direction you described. It is a signal from an endpoint to a stateful middlebox that there are no further packets coming on this connection ID.

As for your use case, this is the first I've heard of the response to a PUBLIC_RESET being "I'll try the same connection ID on a different path". That is an entirely different purpose than what has been described to date. In fact, I believe the consensus is to not allow middleboxes to generate authentic resets.

[mcmanus]

A week ago we discussed whether non-endpoints should be able to generate PR. The folks in the conversation were opposed (as am I!) but the conversation was also clear acknowledging that there was not consensus on that point yet. https://mailarchive.ietf.org/arch/msg/quic/uUpUZiCKW2Lf_Z_DtC0cEHev9dU

The editor's draft currently explicitly allows middleboxes to generate resets.

In the comment this issue begins with (#353 (comment)) he says that a PR that could replace CLOSE is not something that could be authenticated.. which I interpret as not-yet-presupposing pull #20 which lets on-path middleboxes do that.

If we did have consensus on pull #20, then this issue would be ok by me. Is that the crux of the issue?

So maybe issue #215 blocks this?

[martinthomson]

@mcmanus, I think that we do have consensus on #20, but that's not official. I have been assuming that we would build something like that - if we kept a Public Reset at all. Otherwise I don't think that we meet the goal of being resilient against attacks from unauthenticated actors.

I think that part of the problem with Public Reset is that the authenticated version is a connection termination, whereas an unauthenticated (from-the middle) version is fundamentally different. At best, a middlebox can tell you that the path is dead. And yes, the right answer is to route around that middlebox. That would be easier with multipath.

[martinduke]

I agree that this is completely dependent on #20, or something similar.

[mikkelfj]

The current formulation appears to assume that PUBLIC_RESET is only for servers. But a QUIC connection could be symmetrical. So if the purpose is to tear down a connection, both endpoints should have equal opportunity - or at least it should be explained why this is not possible (e.g. reliance on public CA).

A PUBLIC_RESET could be verified by sending a HMAC key during handshake but middleboxes would not be able to verify. It is very difficult for middleboxes to verify a reset without getting a CA involved. Middle boxes might (incorrectly) react to an unverified reset which is an on-path attack vector.

Trusted middleboxes could a have a public key on which they can receive a teardown key - but that is a huge and complex issue.

The problems with PUBLIC_RESET appear to be non-trivial given that large scale on-path attacks do exist - so perhaps replace public reset with an ACK missing approach for teardown, and have a separate concern for middle boxes.

[mnot]

Discussed in Paris; OBE. Martin to open a new issue.