New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace CONNECTION_CLOSE with Public Reset #353

Closed
martinthomson opened this Issue Mar 2, 2017 · 12 comments

Comments

Projects
None yet
7 participants
@martinthomson
Member

martinthomson commented Mar 2, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@ianswett

ianswett Mar 2, 2017

Contributor

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.

Contributor

ianswett commented Mar 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Mar 2, 2017

Member

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

Member

martinthomson commented Mar 2, 2017

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

@mirjak

This comment has been minimized.

Show comment
Hide comment
@mirjak

mirjak Mar 2, 2017

Contributor

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.

Contributor

mirjak commented Mar 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mcmanus

mcmanus Mar 2, 2017

Contributor

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.

Contributor

mcmanus commented Mar 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@martinduke

martinduke Mar 2, 2017

Contributor

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.

Contributor

martinduke commented Mar 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mcmanus

mcmanus Mar 2, 2017

Contributor
Contributor

mcmanus commented Mar 2, 2017

@martinduke

This comment has been minimized.

Show comment
Hide comment
@martinduke

martinduke Mar 2, 2017

Contributor

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

Contributor

martinduke commented Mar 2, 2017

(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

This comment has been minimized.

Show comment
Hide comment
@mcmanus

mcmanus Mar 2, 2017

Contributor

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?

Contributor

mcmanus commented Mar 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Mar 2, 2017

Member

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

Member

martinthomson commented Mar 2, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@martinduke

martinduke Mar 9, 2017

Contributor

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

Contributor

martinduke commented Mar 9, 2017

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

@mikkelfj

This comment has been minimized.

Show comment
Hide comment
@mikkelfj

mikkelfj Apr 24, 2017

Contributor

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.

Contributor

mikkelfj commented Apr 24, 2017

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 mnot added this to Closing, Shutdown, Reset in QUIC Apr 28, 2017

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Jun 7, 2017

Member

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

Member

mnot commented Jun 7, 2017

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

@mnot mnot closed this Jun 7, 2017

@martinthomson martinthomson removed this from Closing, Shutdown, Reset in QUIC Jun 7, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment