<!DOCTYPE html> <html> <head> <title></title> </head> <body><div>I haven't written any drafts but I'm willing to take the plunge for a first draft to get the ball rolling.<br></div> <div><br></div> <div>Maybethe simplest setup would be to leave the handshake itself unchanged and instead define an ExplicitNonceCipherState which encapsulates all the logic needed? The extension would just specify that Split() will break into two of these instead of the default CipherState.<br></div> <div><br></div> <div>Applications would be responsible for ensuring the order and integrity of the handshake messages before noise reaches the transport state.</div> <div><br></div> <div>On Mon, Jun 12, 2017, at 09:52 AM, Trevor Perrin wrote:<br></div> <div>> On Mon, Jun 12, 2017 at 12:34 PM, Jake McGinty <me@jake.su> wrote:<br></div> <div>> > Right now, the Noise spec is unusable for applications that work better<br></div> <div>> > over lossy transports (gaming or video chat) due to the fact that<br></div> <div>> > CipherState only works with an implicit nonce, so dropped and out-of-<br></div> <div>> > order packets won’t fare well.<br></div> <div>><br></div> <div>> Sure!, definitely worth exploring, e.g. it would be fun to think about<br></div> <div>> DTLS/SRTP alternatives for WebRTC.<br></div> <div>><br></div> <div>> It would be easy to link something from the Wiki if you had a draft.<br></div> <div>><br></div> <div>> I haven't looked at this part of WireGuard that much, so I'm not sure<br></div> <div>> what else might be needed (e.g., how do you deal with packet loss<br></div> <div>> during handshake?).<br></div> <div>><br></div> <div>> Of course you should talk to WireGuard about their experiences, and<br></div> <div>> see if this could align with them and be useful for them, too.<br></div> <div>><br></div> <div>> Trevor<br></div> <div><br></div> </body> </html>