Subject: [quicwg/base-drafts] Connection abort during handshake (#597)

From: MikkelFJ <[email-masked]>
Date: Tue, 06 Jun 2017 12:28:06 -0700

The transport document is not very clear on how to handle errors during handshake. TLS 1.3 section 6.2 says to abort connection and send a simple error. This can be done in client or server cleartext packets.

However, a server, or a client, may be jammed with error messages from an adversary. For servers, this can be mitigated by veryfing the Connection Id before accepting the TLS error message. For clients this is not so simple because not all server clear text messages contain the CCID. In a traditional browser client this may not be a big deal, but for peer2peer between two servers, this could be a problem.

A solution could be have all server cleartext packets contain CCID in addition to SSID, similar to how Stateless Retry packets are protected, except that Stateless Retry does not also have a SSID.

The draft does not mention explicitly that cleartext packets with CONNECTION_CLOSE or GO_AWAY should be dropped, but if they are not, the same issue may happen during handshake. It would be helpful with some very explicit text about how to ignore packets and close connections when unexpected payload appears.

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

---

From: MikkelFJ <[email-masked]>
Date: Tue, 06 Jun 2017 13:34:55 -0700

Related: QUIC_INVALID_VERSION_NEGOTIATION_PACKET could be sent by an adversary if CONNECTION_CLOSE frames are permitted in cleartext, and if not, the error is useless unless forwarded to TLS.

-- 
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/597#issuecomment-306608938

---

From: Jānis <[email-masked]>
Date: Tue, 06 Jun 2017 23:23:40 -0700

Well thats why I think this is another reason for using Server Stateless Retry, which returns client's selected random packet number and can be validated by client. It would be hard for attacker to guess that value (2^31).
But protecting against that when server can change CID in ServerCleartext in current design doesn't seem to be possible.

-- 
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/597#issuecomment-306698709

---

From: MikkelFJ <[email-masked]>
Date: Tue, 06 Jun 2017 23:46:53 -0700

>Well thats why I think this is another reason for using Server Stateless Retry, which returns client's selected random packet number and can be validated by client. It would be hard for attacker to…

On using packet numbers for validation: I think it would be simpler to validate on a client and a server chosen nonce (aka Connection Id) because it requires less state, but I might be missing something. For example if failing on a second Client ClearText packet you need to remember all packet numbers and while retransmission does this, it is a different machinery. Having the nonces also simplifies state lookup.

-- 
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/597#issuecomment-306702712

---

From: MikkelFJ <[email-masked]>
Date: Tue, 06 Jun 2017 23:51:15 -0700

I guess one counter argument to my issue is that the 5-tuple is hard to guess for an observer, but it really is only one port number that is hard to guess, and that port number might not be generated as random as one would hope on all platforms.

-- 
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/597#issuecomment-306703550

---

From: Patrick McManus <[email-masked]>
Date: Wed, 07 Jun 2017 01:07:36 -0700

> The draft does not mention explicitly that cleartext packets with CONNECTION_CLOSE or GO_AWAY should be dropped, but if they are not, the same issue may happen during handshake. 

the draft does whitelist which frame types are valid in the various cleartext packets (generally some combination of stream ack and padding) which I think covers this particularly (quoted) concern.

-- 
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/597#issuecomment-306721793

---

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

Is #608 a more succinct description of this issue?

Note that CONNECTION_CLOSE isn't available to us right now, though we could easily permit it.

-- 
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/597#issuecomment-306795086

---

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

> Is #608 a more succinct description of this issue?

More succint, but does not capture pitfalls.

-- 
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/597#issuecomment-306795705

---

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

I think that we need to maintain some degree of clarity about issues rather than try to burden them with every imaginable related problem.  Can we try to reduce complexity rather than increase it?

-- 
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/597#issuecomment-306799770

---

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

See TCP Reset attack : https://www.utc.edu/center-information-security-assurance/pdfs/course-paper-5620-attacktcpip.pdf

-- 
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/597#issuecomment-306806416

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 20 Jun 2017 16:48:33 -0700

Closing in favour of #608. Folks there can refer to discussion here as necessary.

-- 
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/597#issuecomment-309922934

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 20 Jun 2017 16:48:34 -0700

Closed #597.

-- 
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/597#event-1131994663