Rolling keys without service interuption

Rolling keys without service interuption

[Ferris Ellis]

I was wondering if WireGuard supported dynamically updating / rolling keys f=
or connections? In many operations security models credentials are short liv=
ed and rotated regularly so that the consequences of any compromise can be m=
inimized. One problem, however, with this is that rolling credentials often c=
auses a service interrupt for the connection being rolling. Does WireGuard h=
ave a way to do this currently?

I wanted to ask the mailing list about this both for my own knowledge and fo=
r public documentation. Though, I presume the answer is no as WireGuard uses=
 the keys as identity primitives for connections (which I think is the most h=
onest means of relating identity to authorization) and thus =E2=80=9Crolling=
=E2=80=9D them makes no sense.

Cheers,
Ferris

Re: Rolling keys without service interuption

[Aaron Jones]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/12/17 02:45, Ferris Ellis wrote:
> I was wondering if WireGuard supported dynamically updating / 
> rolling keys for connections? In many operations security models 
> credentials are short lived and rotated regularly so that the 
> consequences of any compromise can be minimized. One problem, 
> however, with this is that rolling credentials often causes a 
> service interrupt for the connection being rolling. Does WireGuard 
> have a way to do this currently?
> 
> I wanted to ask the mailing list about this both for my own 
> knowledge and for public documentation. Though, I presume the 
> answer is no as WireGuard uses the keys as identity primitives for 
> connections (which I think is the most honest means of relating 
> identity to authorization) and thus “rolling” them makes no sense.

As far as I understand it, you can dynamically add a new peer to the
interface with wg(8) with the same configuration (including Allowed
IPs and Endpoint) and then remove the old peer. If you are running
reliable protocols on top (e.g. TCP) their retransmit logic will
establish a new session with the 'new' peer for you.

Regards,
Aaron Jones

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJaIjXEAAoJEIrwc3SIqzAS2yUP/273JhlzYzJREMVzvNyfx2cj
sNImcmTFQhFB8SaSxM7u5yY9FtOSgvEyx+jFBhywVOEQfMFXwCtZL6XIXgLsoaM+
GN2NpY+2I95JYOFO6SF0jm4jy3dj0UAZMRctNuM2nasH31jI+E6VDwPcxGsg2o6g
2Am7ykHXETOZBRG9ZXeQiHiQ9ai3RMbrhP2yiApwzoZg3VsookDN+GEJ/K+ZVxaP
n0r9KbvOOn4rEnQSB+GSADl2uihaJu/ziiSMSlbsbkjS5yoBhI8v3GQvpWGCsdu9
hXOR+pmefDsHmurDpBniPWn9epX4aMnOLxzni7WPc3OlgHQg3ZhmvHjW4FrCjX+n
NDfmcbOxvlcMBhPfoLMk8KJMiWZ2k1yGT4yFYynS99NQ7cFcmQhetAKFochz92OX
AJT/bH7ExqQtxYhK1YR+rhw9HhzyhykQC70B1Kp2F9uVBjdKERHM1saavLxBAjlt
U297jzwqxlVji5h2sWHaflPTSnTyx49jSp3ZCPeJ3N57zHzhOmuuyf76CfoE4do+
/RzUhP96JwWIM6Q4HR/MY7UWHHKvt9GW3M+AwTIRovpL0OFPfuOotXc9fW7F25D2
gdWJSOxza7d31YgU7XnkVdHeY6T+uQrx77yjAnmSTcVPIiQlBzBNXE/jTAFA2uEG
Mj71hyihwWkfWOVREg7M
=naHE
-----END PGP SIGNATURE-----

Re: Rolling keys without service interuption

[Jason A. Donenfeld]

Hi Ferris,

Firstly, WireGuard already has forward secrecy, which means every new
session (negotiated every 2 minutes) has fresh keys that are
forgotten, so old recorded traffic cannot be compromised.

It sounds like, however, you want to rotate the long term static
"identity" keys. This is possible to do gracefully. If you change the
private key of an interface, it won't actually be used until the next
handshake occurs, which means you can rollover gracefully. Likewise
you can add new peers (via public keys) dynamically at runtime. Moving
a distinct allowed IP from one peer to another is an atomic operation
as well.

Hope this helps!

Regards,
Jason

Re: Rolling keys without service interuption

[Ferris Ellis]

Jason,

Awesome! That=E2=80=99s exactly what I needed :) I=E2=80=99ll try it out and=
 post a follow up if I have any issues.

Cheers,
Ferris

> On Dec 2, 2017, at 8:31 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>=20
> Hi Ferris,
>=20
> Firstly, WireGuard already has forward secrecy, which means every new
> session (negotiated every 2 minutes) has fresh keys that are
> forgotten, so old recorded traffic cannot be compromised.
>=20
> It sounds like, however, you want to rotate the long term static
> "identity" keys. This is possible to do gracefully. If you change the
> private key of an interface, it won't actually be used until the next
> handshake occurs, which means you can rollover gracefully. Likewise
> you can add new peers (via public keys) dynamically at runtime. Moving
> a distinct allowed IP from one peer to another is an atomic operation
> as well.
>=20
> Hope this helps!
>=20
> Regards,
> Jason