Subject: [quicwg/base-drafts] How do we signal handshake errors (#608)

From: Martin Thomson <[email-masked]>
Date: Wed, 07 Jun 2017 06:27:41 -0700

If the handshake fails, how do we signal that?  We could send CONNECTION_CLOSE in the clear...

If version negotiation fails, how do we signal that?  I don't think that we can, though we currently require that.

-- 
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/608

---

From: MikkelFJ <[email-masked]>
Date: Wed, 07 Jun 2017 06:31:10 -0700

Sending in clear would allow adversaries to close the connection if they can guess the tuple.

-- 
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/608#issuecomment-306795213

---

From: Martin Thomson <[email-masked]>
Date: Wed, 07 Jun 2017 07:20:55 -0700

This is a valid concern.  Note that an adversary is able to interrupt a connection in many ways prior to the establishment of a shared key.  For example, a spurious Version Negotiation packet, a modified TLS handshake message, many things...  Some of those are quite hard to detect.

-- 
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/608#issuecomment-306809849

---

From: MikkelFJ <[email-masked]>
Date: Wed, 07 Jun 2017 07:27:22 -0700

There are many topics overlapping this by now - including https://github.com/quicwg/base-drafts/issues/554

I believe all of these can be sufficiently mitigated by having a server and client nonce in all packets. An attacker needs to guess the nonce which is hard for 64-bit - combined with FNV-1a checksum it is probably very hard to attack off-path.

-- 
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/608#issuecomment-306811791