Add warning about request forgery and client-side migration

[ekr]

I find Martin's argument that QUIC servers are able to control their topology well enough to prevent request forgery attacks somewhat persuasive. However:

1. I think the document should be clearer that if you can't do this you can't deploy QUIC as a server.
2. We should add text indicating that a candidate extension to allow migration by the client would need to deal with this (likely by adding one of the countermeasures we decided not to ass). This is a very long specification and otherwise the institutional knowledge about this issue is likely to be lost.

[ekr]

If people agree, I can provide PRs for these.

[martinthomson]

These sound like good additions that I would welcome. (I would write the PR, but I don't trust myself, I'd appreciate you providing text.)

[LPardue]

Sounds like a good path forward.

[MikeBishop]

2. We should add text indicating that a candidate extension to allow migration by the client would need to deal with this (likely by adding one of the countermeasures we decided not to ass). This is a very long specification and otherwise the institutional knowledge about this issue is likely to be lost.

Do you mean migration by the server?

[ekr]

I'm not clear on the grammar, but I mean "the server address changing"

…

On Fri, Sep 11, 2020 at 7:56 AM Mike Bishop ***@***.***> wrote: 1. We should add text indicating that a candidate extension to allow migration by the client would need to deal with this (likely by adding one of the countermeasures we decided not to ass). This is a very long specification and otherwise the institutional knowledge about this issue is likely to be lost. Do you mean migration by the server? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4086 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIPLIP2O65HJHDOBLREVWLSFI3ANANCNFSM4REBBT4A> .

[MikeBishop]

FWIW, when we've talked about a server migration extension before, it was usually in the form of a frame that mimics the preferred_address TP, prompting the client to probe the new address and actually make the change. That approach seems like it limits the attacks to those already possible with SPA, though it broadens the window / number of attempts.

[larseggert]

Could people take a look at the PR? Would like to move this along.