Subject: [quicwg/base-drafts] Need a NONCE in version negotiation packets (#244)

From: Igor Lubashev <[email-masked]>
Date: Thu, 26 Jan 2017 15:11:41 -0800

Now that the client does not send a connection id in its version negotiation (see #119), client needs a public nonce in the packets. That prevents an off-path attacker guessing client source port and interfering with the client establishing connections with a given sever by spoofing version negotiation failure packets as if coming from that sever. That nonce should be returned by the sever in its version negotiation packets. Previously, client's connection id served such a purpose.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/244

---

From: ianswett <[email-masked]>
Date: Sat, 28 Jan 2017 05:14:51 -0800

The public reset has the same issue.

I'm not sure how serious an issue this is, since the attacker would also have to guess the server IP and port as well as the client port.  In practice, this would be a very costly attack, because it only works during the handshake.  Typically handshakes complete within a second, so to prevent a client from connecting to a single IP/port, you'd have to send thousands of packets a second, with no guarantee or acknowledgement of whether your attack was a success?

If we think it's a serious issue, we could also reconsider requiring a connection id from client to server on the initial flight. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/244#issuecomment-275847553

---

From: Martin Thomson <[email-masked]>
Date: Sun, 29 Jan 2017 14:35:24 -0800

Connection ID isn't the only field that contains entropy.  As you say, IP and port do contain some entropy (though not much).  Requiring proof that the server received a packet doesn't have to rely on those fields alone.  That gets easier if you don't worry about version negotiation packets because you can put things in the TLS handshake (something that we might want to do anyway).

There really isn't anything very strong in the TLS ServerHello.  The messages that follow have a *very* strong signal that the server received the ClientHello though.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/244#issuecomment-275951983

---

From: mirjak <[email-masked]>
Date: Mon, 30 Jan 2017 07:45:36 -0800

The packet number and a potential packet number echo from the server would help here as well.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/244#issuecomment-276097507