WireGuard Upstreaming Roadmap (November 2017)

[Jason A. Donenfeld]

On Thu, Dec 7, 2017 at 10:57 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> On Thu 2017-12-07 07:37:59 -0600, Bruno Wolff III wrote:
>> On Thu, Dec 07, 2017 at 11:22:04 +0100,
>>   Stefan Tatschner <rumpelsepp at sevenbyte.org> wrote:
>>>
>>>Assuming I am right according the crypto agility, what's the upgrade
>>>path if any of the involved cryptographic algorithms will be declared
>>>insecure/broken? From my point of view wireguard tries to stay as
>>>simple as possible and in general that's a good idea. I am just a bit
>>>worrying about the possible lack of a clear upgrade path once
>>>wireguard is mainlined.
>>
>> Having alternate crypto paths is also a weakness. There have been lots of
>> downgrade attacks against systems that incorporate agility.
>
> this is clearly true, but it doesn't answer the question that Stefan was
> asking.
>
> As i understand it, for the current form of wireguard, the only way to
> resolve the sort of problem described will be to create a "wireguard2"
> which uses new, better primitives.  and it will probably need to listen
> on a different port than "traditional wireguard" if you have any intent
> on supporting both variants at the same time on the same host.
>
> As upgrade paths go, this isn't too terrible, but it's not exactly
> pretty either.  it'd be great to hear if folks have better ideas.

Moved this to another thread.