Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Bruno Wolff III <bruno@wolff.to>,
	Stefan Tatschner <rumpelsepp@sevenbyte.org>
Cc: wireguard@lists.zx2c4.com
Subject: Re: WireGuard Upstreaming Roadmap (November 2017)
Date: Thu, 07 Dec 2017 16:57:58 -0500	[thread overview]
Message-ID: <878tee2obd.fsf@fifthhorseman.net> (raw)
In-Reply-To: <20171207133759.GA395@wolff.to>

[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]

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

   --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2017-12-07 22:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-11  4:48 Jason A. Donenfeld
2017-12-07 10:22 ` Stefan Tatschner
2017-12-07 13:37   ` Bruno Wolff III
2017-12-07 21:57     ` Daniel Kahn Gillmor [this message]
2017-12-08  2:25       ` Jason A. Donenfeld
2017-12-08  6:58         ` Stefan Tatschner
     [not found]   ` <CAHmME9rhB-w=EoUJ-EiT1cgJKS44Uz=uJdphsud-BEN1zHtB9A@mail.gmail.com>
     [not found]     ` <20171208.103841.516344129530992484.davem@davemloft.net>
2017-12-08 18:19       ` Jason A. Donenfeld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878tee2obd.fsf@fifthhorseman.net \
    --to=dkg@fifthhorseman.net \
    --cc=bruno@wolff.to \
    --cc=rumpelsepp@sevenbyte.org \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).