Subject: [quicwg/base-drafts] ClientHello needs to fit in a single packet (#338)

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Feb 2017 21:18:25 -0800

I'm marking this as editorial.  It touches both TLS and transport.  Anyone who thinks that this is OK can merge it.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/338

-- Commit Summary --

  * ClientHello needs to fit in a single packet
  * Reword DoS risk text

-- File Changes --

    M draft-ietf-quic-tls.md (31)
    M draft-ietf-quic-transport.md (10)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/338.patch
https://github.com/quicwg/base-drafts/pull/338.diff

-- 
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/pull/338

---

From: janaiyengar <[email-masked]>
Date: Wed, 22 Feb 2017 23:36:24 -0800

janaiyengar commented on this pull request.

> @@ -487,6 +487,29 @@ version of TLS.  An endpoint MUST terminate the connection if a version of TLS
 older than 1.3 is negotiated.

+## ClientHello Size
+
+QUIC requires that the initial handshake packet from a client fit within a
+single packet of 1280 octets.  With framing and packet overheads this value
+could be reduced.
+
+A TLS ClientHello can fit within this limit with ample space remaining.
+However, there are several variables that could cause this limit to be exceeded.
+Implementations are reminded that large session tickets or HelloRetryRequest
+cookies, multiple or large key shares, and long lists of supported ciphers,
+signature algorithms, versions, and other negotiable parameters and extensions
+could cause this message to grow.

This also needs to inclde the transport params, right?

> @@ -1223,11 +1246,11 @@ by an attacker.
 Certificate caching {{?RFC7924}} can reduce the size of the server's handshake
 messages significantly.
 
-A client SHOULD also pad {{!RFC7685}} its ClientHello to at least 1024 octets.
+QUIC requires that the packet containing a ClientHello be padded to 1280 octets.

"at least 1280 octets"

> @@ -697,6 +697,16 @@ the cryptographic handshake provides QUIC with:
   client can receive packets that are addressed with the transport address that
   is claimed by the client (see {{source-address-token}})
 
+The initial cryptographic handshake message needs to be sent in a single packet.
+This avoids having to reassemble a message from multiple packets. This would
+require that servers maintain state prior to establishing a connection, exposing
+servers to a denial of service risk.

Phrasing unclear. How about "This avoids having to reassemble a message from multiple packets since doing so would require that a server maintain state prior to establishing a connection, exposing the server to a denial of service risk."

> @@ -697,6 +697,16 @@ the cryptographic handshake provides QUIC with:
   client can receive packets that are addressed with the transport address that
   is claimed by the client (see {{source-address-token}})
 
+The initial cryptographic handshake message needs to be sent in a single packet.
+This avoids having to reassemble a message from multiple packets. This would
+require that servers maintain state prior to establishing a connection, exposing
+servers to a denial of service risk.
+
+The first client packet of the cryptographic handshake protocol MUST fit within
+a 1280 octet QUIC packet.  this includes overheads that reduce the space

I don't think we're requiring 1280 bytes, just that it fit within a packet, right? We talk about MTU elsewhere, how about just saying that this packet MUST fit within a single QUIC packet, assuming that the packet is MTU-sized or smaller?

-- 
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/pull/338#pullrequestreview-23412899

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Feb 2017 16:38:29 -0800

martinthomson commented on this pull request.

Well, we can't exclude implementations that choose to only send 1280 octet packets.  That would be unwise, I think.  This is MORE strict, I agree, but I think that we want to specifically exclude handshake packets that exceed this or we will find that they aren't properly applicable across multiple networks and use cases.  

If a handshake packet grows too much, then we limit this to networks that can handle a larger MTU.  Given that we don't need the space right now, this seems like a constraint that won't be hard to meet.

-- 
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/pull/338#discussion_r102855555

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Feb 2017 16:38:59 -0800

@martinthomson pushed 1 commit.

ade3e2e  Rephrase a little based on a second reading and review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/338/files/0e85a9318f9d6f7f5c072e75b3e4b59bd554aa6c..ade3e2eafd3b93a889157cf87bb079a94a643715

---

From: janaiyengar <[email-masked]>
Date: Thu, 23 Feb 2017 22:44:08 -0800

+## ClientHello Size
+

"at least 1280 octets."

> @@ -697,6 +697,17 @@ the cryptographic handshake provides QUIC with:
 
+The initial cryptographic handshake message MUST be sent in a single packet.
+Any second attempt that is triggered by address validation MUST also be sent
+within a single packet.  This avoids having to reassemble a message from
+multiple packets.  Reassembling messages requires that a server maintain state
+prior to establishing a connection, exposing the server to a denial of service
+risk.
+
+The first client packet of the cryptographic handshake protocol MUST fit within
+a 1280 octet QUIC packet.  This includes overheads that reduce the space

change "1280 octet" to "MTU-sized"

-- 
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/pull/338#pullrequestreview-23657127

---

From: ianswett <[email-masked]>
Date: Fri, 24 Feb 2017 09:01:40 -0800

ianswett approved this pull request.

-- 
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/pull/338#pullrequestreview-23761435