Re: Error handling and Public Reset

[Eric Rescorla <[e-mail]>]

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


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

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