Subject: Error handling and Public Reset

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Feb 2017 11:29:05 +1100

I've put together a PR (hehe) that attempts to close on the discussion
we've had about public reset.  I've expanded it to include more
details on error handling.  This includes discussion on what to do
with connection close.

I have not added anything about what to do with undelivered data.
That will follow once the current discussion concludes.

https://github.com/quicwg/base-drafts/pull/335

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 23 Feb 2017 04:48:26 -0800

There's been a fair amount of discussion on this PR, but it seems like
we first need to resolve the high level design issue of who can send a
public reset. Specifically:

- Off-path elements
- On-path elements which are not endpoints
- Endpoints

I think we agree that off-path elements should not be able to send
acceptable public resets, but disagree about whether on-path elements
which are not endpoints should be able to do so and if so whether they
should be distinguishable from those sent by endpoints. As I indicated
in PR#20 and the subsequent discussion, I don't think it's ideal for
on-path elements to be able to send public resets because this leads
to easy Great Firewall "man-on-the-side" type attacks, and it is
possible to design a public reset mechanism in which the endpoints can
have minimal persistent state and yet generate public resets that
cannot be forged. If we add such a mechanism we can also, if we like,
add one that allows on-path elements to generate public resets, but
because these are weaker, they should be distinguishable so that
endpoints can reject them.

I recognize that there isn't consensus on this view -- at least no
declared consensus -- though I don't believe that the contrary view
has consensus either, but I think we need to resolve this before
dealing with PR#335.

-Ekr

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 23 Feb 2017 11:38:12 -0800

My preference would be that valid public reset packet should only be able
to be generated by endpoints, for exactly the reasons you lay out in PR#20.

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 23 Feb 2017 11:48:05 -0800

As I mentioned on the PR, I'm not in favor of specifying middlebox use of
public reset.

That said, without PR#20, I don't understand how a client would know the
difference between an on-path middlebox and an endpoint sending a PR.
Neither has keys for the connection and both will be able to see the same
parts of the packet. I agree that we need to resolve PR#20 before getting
to PR#335.

On Thu, Feb 23, 2017 at 11:38 AM, Ryan Hamilton <[email-masked]> wrote:

>> On Wed, Feb 22, 2017 at 4:29 PM, Martin Thomson <[email-masked]
>> > wrote:
>>

---

From: Ian Swett <[email-masked]>
Date: Thu, 23 Feb 2017 14:55:24 -0500

I agree with EKR's proposal and would like all public resets to be only
sent by endpoints and verifiable.

If we did allow on-path, non-endpoints to send public resets, they should
be easy to distinguish from those of endpoints, but at this point, I've
heard no clear argument for why these are necessary, so I don't see a need
to specify them.

On Thu, Feb 23, 2017 at 2:48 PM, Jana Iyengar <[email-masked]> wrote:

>>> On Wed, Feb 22, 2017 at 4:29 PM, Martin Thomson <
>>> [email-masked]> wrote:
>>>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 23 Feb 2017 12:13:51 -0800

> parts of the packet. I agree that we need to resolve PR#20 before getting

Yes, I think that's the right conclusion. I do think we can land your
header patch with a
[TODO] in this slot because it's a self-contained issue.

-Ekr

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 23 Feb 2017 12:15:27 -0800

> [TODO] in this slot because it's a self-contained issue.

Agreed. (I'll get a PR for the header proposal soon.)

>>> My preference would be that valid public reset packet should only be
>>> able to be generated by endpoints, for exactly the reasons you lay out in
>>> PR#20.
>>>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Feb 2017 14:13:32 +1100

> Agreed. (I'll get a PR for the header proposal soon.)

Based on this (I was just hoping to include what was in the draft), it
seems like it would be easier to require that unauthenticated public
resets be dropped.  We can later decide whether to include a proof
that consists of "I saw a packet from you" as opposed to "I was part
of the initial connection setup" if that is the way the wind blows on
that day.

I have excised the offending text.  I would prefer to make progress on
those parts that I was really trying to hit: how to signal errors, not
overusing public resets, and so forth.