Subject: [quicwg/base-drafts] Replace CONNECTION_CLOSE with Public Reset (#353)

From: Martin Thomson <[email-masked]>
Date: Wed, 01 Mar 2017 16:42:39 -0800

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

-- 
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/353

---

From: ianswett <[email-masked]>
Date: Wed, 01 Mar 2017 17:43:12 -0800

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.

-- 
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/353#issuecomment-283529953

---

From: Martin Thomson <[email-masked]>
Date: Wed, 01 Mar 2017 19:08:20 -0800

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

-- 
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/353#issuecomment-283543074

---

From: mirjak <[email-masked]>
Date: Thu, 02 Mar 2017 01:49:30 -0800

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.

-- 
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/353#issuecomment-283606930

---

From: Patrick McManus <[email-masked]>
Date: Thu, 02 Mar 2017 04:53:48 -0800

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.

-- 
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/353#issuecomment-283645847

---

From: martinduke <[email-masked]>
Date: Thu, 02 Mar 2017 09:13:26 -0800

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

-- 
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/353#issuecomment-283716658

---

From: Patrick McManus <[email-masked]>
Date: Thu, 02 Mar 2017 09:51:26 -0800

On Thu, Mar 2, 2017 at 12:13 PM, martinduke <[email-masked]>
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.

-- 
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/353#issuecomment-283727431

---

From: martinduke <[email-masked]>
Date: Thu, 02 Mar 2017 09:58:54 -0800

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

-- 
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/353#issuecomment-283729446

---

From: Patrick McManus <[email-masked]>
Date: Thu, 02 Mar 2017 10:37:00 -0800

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 (https://github.com/quicwg/base-drafts/issues/353#issue-211254850) 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?

-- 
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/353#issuecomment-283739722

---

From: Martin Thomson <[email-masked]>
Date: Thu, 02 Mar 2017 15:11:50 -0800

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

-- 
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/353#issuecomment-283813080

---

From: martinduke <[email-masked]>
Date: Thu, 09 Mar 2017 14:00:43 -0800

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

-- 
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/353#issuecomment-285497404