Subject: [quicwg/base-drafts] Tolerate unknown stream types, add greasing (#1525)

From: Mike Bishop <[email-masked]>
Date: Thu, 05 Jul 2018 10:24:16 -0700

Fixes #1490.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Tolerate unknown stream types

-- File Changes --

    M draft-ietf-quic-http.md (38)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1525.patch
https://github.com/quicwg/base-drafts/pull/1525.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/1525

---

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Jul 2018 17:00:40 -0700

martinthomson approved this pull request.

Seems reasonable to me.

>  unknown. Implementations SHOULD NOT send stream types the peer is not already
-known to support, since a stream error can be promoted to a connection error at
-the peer's discretion (see {{errors}}).
+known to support. Recipients of unknown stream types MAY trigger a QUIC
+STOP_SENDING frame with an error code of HTTP_UNKNOWN_STREAM_TYPE, but MUST NOT
+consider such streams to be an error of any kind.

You might want to point out that these cannot include QPACK header blocks unless that is explicitly negotiated.

-- 
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/1525#pullrequestreview-134853553

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 06 Jul 2018 07:40:18 -0700

LPardue commented on this pull request.

-known to support, since a stream error can be promoted to a connection error at
-the peer's discretion (see {{errors}}).
+known to support. Recipients of unknown stream types MAY trigger a QUIC
+STOP_SENDING frame with an error code of HTTP_UNKNOWN_STREAM_TYPE, but MUST NOT
+consider such streams to be an error of any kind.
+
+### Reserved Stream Types {#stream-grease}
+
+Stream types of the format `0x1f * N` are reserved to exercise the requirement
+that unknown types be ignored. These streams have no semantic meaning, and can
+be sent when application-layer padding is desired.  They MAY also be sent on

What do you mean by application-layer padding in this case? If this is some property of the mapping that can be used to add additional padding to QUIC's PADDING frames then is it worth pointing out in security considerations?

-- 
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/1525#pullrequestreview-135040694

---

From: Mike Bishop <[email-masked]>
Date: Fri, 06 Jul 2018 09:43:17 -0700

MikeBishop commented on this pull request.

Perhaps.  HTTP/2 allowed padding on the HEADERS and DATA frames, to make analysis of the traffic more difficult.  QUIC can pad individual packets to different / uniform sizes, but I'm assuming that most stacks won't generate traffic where none exists.  An application layer can make analysis more difficult by sending traffic even when no requests are happening.

-- 
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/1525#discussion_r200708927

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 06 Jul 2018 10:43:13 -0700

Ok so I get the problem, this is more like a background level of noise.

I guess I had been expecting transport libraries to handle packing and padding with some influence from the application. It wouldn't be a stretch for them to provide an API that would allow the caller to declare a background level of traffic, however the transport won't have any stream to send this on.

In that case, I like the side effect of this.

-- 
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/1525#discussion_r200724410

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 06 Jul 2018 10:45:09 -0700

LPardue 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/1525#pullrequestreview-135101464

---

From: Mike Bishop <[email-masked]>
Date: Fri, 06 Jul 2018 10:58:16 -0700

@MikeBishop pushed 1 commit.

2cf8b43  Prohibit speculative stream type use that modifies core protocol

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1525/files/e547427ca03c0a3928374ae7af39561271ab26e7..2cf8b436d470d55a9bcef2bc719ddbec4270e04c

---

From: Mike Bishop <[email-masked]>
Date: Fri, 06 Jul 2018 11:02:17 -0700

9d5a550  Discuss padding in Security Considerations

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1525/files/2cf8b436d470d55a9bcef2bc719ddbec4270e04c..9d5a5507e8c12d68afb8867456c0011222e112c1

---

From: Mike Bishop <[email-masked]>
Date: Fri, 06 Jul 2018 11:02:31 -0700

Added a mention in Security Considerations.

-- 
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/1525#discussion_r200729336

---

From: Mike Bishop <[email-masked]>
Date: Fri, 06 Jul 2018 11:03:20 -0700

Borrowed the extension language that you MUST NOT send anything that modifies the state of the core protocol, QPACK, or any other extension unless you know the peer supports it.  Do you think that's sufficient?

-- 
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/1525#discussion_r200729508

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 06 Jul 2018 11:42:32 -0700

LGTM

-- 
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/1525#issuecomment-403116021

---

From: janaiyengar <[email-masked]>
Date: Fri, 06 Jul 2018 13:50:38 -0700

janaiyengar commented on this pull request.

A couple of comments

 If the stream header indicates a stream type which is not supported by the
-recipient, this SHOULD be treated as a stream error of type
-HTTP_UNKNOWN_STREAM_TYPE.  The semantics of the remainder of the stream are
-unknown. Implementations SHOULD NOT send stream types the peer is not already
-known to support, since a stream error can be promoted to a connection error at
-the peer's discretion (see {{errors}}).
+recipient, the remainder of the stream cannot be consumed as the semantics are
+unknown. Recipients of unknown stream types MAY trigger a QUIC STOP_SENDING
+frame with an error code of HTTP_UNKNOWN_STREAM_TYPE, but MUST NOT consider such
+streams to be an error of any kind.
+
+Implementations SHOULD NOT send stream types the peer is not already known to
+support.   Stream types which could modify the state or semantics of existing

This text recommends (SHOULD NOT) negotiating supported stream types. Is this recommendation necessary?

> @@ -1651,6 +1670,18 @@ The entries in the following table are registered by this document.
 | Push Stream      | 0x50   | {{server-push}}            | Server |
 | ---------------- | ------ | -------------------------- | ------ |
 
+Additionally, each code of the format `0x1f * N` for values of N in the
+range (0..8) (that is, `0x00`, `0x1f`, etc., through `0xf8`), the following

Let's list them all; it's only 8 values. ('0x00', '0x1f', '0x3e', '0x5d', '0x7c', '0x9b', '0xba', '0xd9', '0xf8').

-- 
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/1525#pullrequestreview-135150465

---

From: Mike Bishop <[email-masked]>
Date: Fri, 06 Jul 2018 14:42:27 -0700

The recommendation is purely because if you send types that aren't supported, you're wasting bandwidth.  It's not an interop issue, so perhaps that doesn't rise to the level of SHOULD NOT.  Would "MAY send" be more affirming?

-- 
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/1525#discussion_r200776947

---

From: Mike Bishop <[email-masked]>
Date: Fri, 06 Jul 2018 14:56:41 -0700

@MikeBishop pushed 2 commits.

7deb076  Loosen prohibition on unknown stream types further
4459244  Multiply for IANA

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1525/files/9d5a5507e8c12d68afb8867456c0011222e112c1..44592445505fc4308e4467277331a07296078bb3

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 06 Jul 2018 14:56:46 -0700

If you want to make that change it would make sense to add the sentence from this paragraph to the previous one e.g. 

_Implementations MAY send stream types the peer is not already known to support. If the recipient does not support a stream type, the remainder of the stream cannot be consumed as the semantics are unknown. (optional: add comment about wasted bandwidth)..._

-- 
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/1525#discussion_r200780118

---

From: Mike Bishop <[email-masked]>
Date: Fri, 06 Jul 2018 15:07:49 -0700

Merged #1525.

-- 
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/1525#event-1721161109

---

From: Martin Thomson <[email-masked]>
Date: Sun, 08 Jul 2018 16:47:13 -0700

martinthomson commented on this pull request.

Yeah.

-- 
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/1525#discussion_r200858916

---

From: Martin Thomson <[email-masked]>
Date: Sun, 08 Jul 2018 16:49:18 -0700

Padding using bogus frames might work, but there are two problems with this:

1. Not all streams use frames.
2. Padding that uses bogus unidirectional streams isn't guaranteed to be placed in the same packet as the data that it pads.

-- 
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/1525#discussion_r200859004