This isn't relevant for a specification.

DIVERSIFICATION_NONCE (0x04) is dead, 0x80 is unused.

The TLS document doesn't really need to include this.

Quoting Martin Duke:

RFC-Compliant ICMP PMTU messages include the
oversize packet's IP header and the first 8 bytes of the transport. This
allows TCP to demultiplex the ICMP to the relevant connection/path, and
check that the echoed sequence number corresponds to an in-flight segment,
and that the segment that would have violated the advertised MTU. As TCP
windows increase, it's true that this may be less effective.

For QUIC, these messages will contain only the UDP header. I believe this is
sufficient to demux to the right connection (QUIC allows the same 4-tuple
for multiple connection IDs, but it would be fine to apply it to all such
connections), but I see no clear mechanism to prevent a blind attacker that
guesses the 4-tuple from forcing a QUIC connection to revert to the min path
MTU. Some possibilities:
(a) Require routers to send more bytes. This is probably not deployable,
and in any case because packet numbers always start at zero this doesn't add
much security.
(b) Store UDP or IP data. We could require QUIC to store the UDP
checksum or IP ID in its send queue, thus allowing it to associate the
returned headers with a packet in its queue. This is ugly from a layering
perspective and may not be plausible with hardware offload of checksums,
various middleboxes, etc.
(c) Isolated DF packets. QUIC could pick a long time interval (10
seconds?) in which is sets DF on a single MTU-sized packet (which may have
to be padded). QUIC would only accept ICMP messages within an RTT or so of
having sent one of these MTU probe packets, or until it's acked. Thus the
probabability an off-path attacker could time it correctly is (RTT / 10
sec). If there's an extended burst of ICMP to overcome this, that's probably
an attack indication to handle either in IP, the firewall, or at worst in
QUIC. I have some language to codify this, and if we agree this is the
right approach I can share it.

We have rules about retransmission of STREAM frames. ACK has similar properties in terms of what needs to be retransmitted. Once an ACK has been acked, what should a sender do when constructing future ACK messages?

There have been proposals on the list. We need to finalize a version number scheme for QUIC versions.

Error handling is rather... distributed in the core protocol spec. The frames to signal errors are there, and there's a long list of error codes, but no generalized discussion of how errors are handled and what stream versus connection-level errors mean.

This isn't defined as being required or optional. Also, it appears to both be mandatory and have a default value.

We need to know what can change between versions.

The critical thing for forward compatibility is the ability to signal that a new version is being used. In order to do so, the recipient (the server here) needs to be able to find the version field. Given the current packet layout, that means that we need to guarantee that the connection ID and version bits behave consistently across versions and that no extra fields are added in between the start of the packet and the version.

Do we want them? How do we accommodate them? What are their semantics if they aren't understood?

There are probably lots of these, which we should include in the transport doc.

Off the top of my head: client, server, peer, endpoint, stream, frame, packet, packet number, stream error, connection error, outstanding/unacknowledged.

More complicated concepts belong in requisite documents: e.g., loss detection, retransmission, and congestion; flights, etc...

This obviously happened in the markdown conversion. We need to fix it.

We might be able to randomize the starting packet number and thereby avoid having it as a point of ossification. It also increases the entropy for an off-path attacker who wishes to guess connection IDs because now they have to guess packet number as well.

The algorithm for picking the length of the packet number needs much better explanation, and probably a bunch of rationale to support that.

(Marked as design so that any change gets proper discussion and review.)

Martin Duke requests that all fields necessary for frame length computation be moved to the start of the frame.

@ianswett suggests that maybe this can be removed. He didn't say why.

As per discussion at the meeting. This will allow QUIC to evolve ahead of any updates to its higher layers.

From @janaiyengar:

We need rules using
packet numbers, such that an old packet with a key phase matching the
current expected should not cause the connection to blow up.

With multiple key updates, there is a possibility that packets from epoch n could collide with packets that were sent in epoch n+2. This is unlikely, but still something implementations need to handle. It's not a problem as such unless you insist that connections blow up on decryption failure (which we shouldn't, that's a DoS vector).

It's also not a really bad problem because we have packet numbers that should identify the reordered packet as belonging to the older epoch. We know what the keys were at that time (if we chose to retain them), so it's not even the case that we need to discard the packet every time.

We currently have no way of advertising things like flow control windows, maximum number of streams, etc...

Candidate is a QUIC extension that we include in the handshake. This can include the QUIC version.

The section on Hybrid Slow Start ends in the mi

It's currently unclear how two QUIC peers opening a connection know which handshake protocol to expect on Stream 1.

Since the client has to include the opening handshake in its first flight, it has to at least be able to guess a handshake protocol that's acceptable to the server and include enough information for the server to know which one it's attempting. Currently all the mechanisms for telling the client to retry with different options are at the TLS layer, which is too late.

How is this negotiated? Is it baked into the QUIC version? Is it specified as part of the application mapping (e.g. the HTTP mapping currently requires the TLS 1.3 handshake to be used) and therefore either supplied as part of the Alt-Svc record or implied by the port?

There's a bunch of places where we want to recommend that the handshake fails. We need an editorial convention for how to write that down, which should include any error codes and messages that are sent at the same time.

Does this need to be MUST use?

None of the sections on various techniques in the loss recovery draft include citations. This is easy for RFCs (just use {{!RFCXXXX}} or {{?RFCXXXX}}), but academic papers will require the creation of a citation in the appropriate references section.

...and as in #8, anything else that isn't relevant.

Not all figures currently do.

We need to write down how this happens:

1. on the same connection
2. on a subsequent connection

Hi,

I believe the RST_STREAM error codes are missing from https://tools.ietf.org/html/draft-hamilton-quic-transport-protocol-01 (there weren't in the previous version either).

These error codes are distinct from other error codes but the enumeration ranges overlap, which causes some unfortunate aliasing. I raised this issue on the QUIC Protocol discussion group (https://groups.google.com/a/chromium.org/forum/#!topic/proto-quic/dSSNpQj3shI) but also raising here to signal when the the I-D gets updated.

If we consider cleartext << 0-RTT << 1-RTT, then we might be able to establish a clear rule regarding acknowledgments.

The desired rule is that an ACK MUST be sent with the same or higher protection.

However: This rule would mean that a server is required to ACK 0-RTT data with 1-RTT keys. That's tricky, because loss or delay of the server's first flight also delays the server's ACKs of 0-RTT data (the server can't use 0-RTT keys).

http://editorconfig.org/

Also need instructions.

Martin Duke observes that until STOP_WAITING is acknowledged, you can't assume that it has had an effect. This means that anything that depends on the number of "in flight" packets can't assume that packets before the Last Unacked packet aren't still considered as in transit by the receiver of the STOP_WAITING. This is particularly relevant for determining how many bits to allocate to packet numbers.

We might just provide advice here, but I've marked this as design so that we can discuss it.

We had consensus in Seoul (which we should reconfirm on the list) about switching from little endian to big endian. This should probably happen in concert with the version number scheme that @martinthomson and @janaiyengar are hashing out.

In h2, we were able to update transport-y parameters like flow control window and number of streams. If we adopt a TLS extension for negotiating/advertising these, that means we can't update them.

The submission was complicated by the fact that the documents cross-reference each other, which makes for some difficulty during the build/submission process. Martin worked around that initially by just changing the references to be by title instead of by I-D name. For the future, however, should we make the documents acyclic? That would require clarifying the interfaces between the components we intend to make separable, which I think is a strictly good thing.

My initial inclination is that the core spec should reference none of the others, and each of the others should reference only the core spec. The HTTP mapping doesn’t care what loss detection or security handshake is used, only that they provide the features needed by QUIC. Currently, we explicitly require that the TLS handshake be used, but I’m not convinced that’s necessary. (Alternately, we could reference the actual TLS RFC and require that “a handshake using TLS” be employed, rather than the particular handshake we’re currently defining.) The loss detection and security components shouldn’t care about each other either, so long as they can trust that the jobs are getting done. The core spec should contain the interfaces for all these intersection points.

Given that we’ve already agreed that we intend these pieces to be modular, I think this is probably an editorial-class change, albeit a big one.

I think that this is one or other peer walking away from a conversation without saying goodbye. If we're going to talk about silent closes, we need to explain what it is, why a peer might choose to do it, and the consequences for everyone involved if they exist.

Also, Martin Duke observes that it's not clear how QUIC would determine that the crypto handshake was incomplete after one message.

I note that this might be aided by #35.

Packet numbers, stream offsets, various ACK information and many other fields can currently be encoded as variable length. Do we have some data on the benefits of this complexity? Would it be sufficient to use fewer increments, or could we even move to fixed length encoding for some or all of these fields?

Sorry for the spam. We only seem to get issue notifications through intermittently.

The design for TLS 1.3 KeyUpdate ensures that a compromise of keys after a KeyUpdate has been completed doesn't result in a compromise of all prior keys on that connection.

This is not true in QUIC. QUIC uses a TLS exporter to obtain its initial seed keys. As long as the exporter secret remains viable (and it will by default in most TLS stacks), then it will be able to compromise any QUIC packet protection keys.

We can't close the TLS connection on stream 1 early because it is desirable to have new session tickets issued to clients over time, especially if a server wants to update keys in response to mobility or other significant events.

We could recommend that TLS stacks provide an API for destroying an exporter secret, but that would interact poorly with things like token binding which use the exporter secret constantly.

The IETF has a common representation for packet headers that most other RFCs follow. Section 3.1 of RFC2360 describes the basic idea, but other more recent RFCs have adopted some extensions (e.g., the HIP protocol).

The QUIC drafts should use the same representation. The current figures don't always have proportional field lengths, don't show bit flags, etc., which IMO is confusing. If we don't want fo fix the figures, I'd rather replace the current figures with a textual list of fields, rather than using something that looks familiar to IETFers but is really something different.

Also, check out http://asciiflow.com/ for making diagrams.

We need to be absolutely explicit here: if unprotecting a packet fails, drop it.

It's important that we have this rule to prevent trivial DoS attacks on connections. Also, we need to make it clear that unauthenticated data does not get fed into the system unless we have very careful rules around how we handle that data.

Issue #64 brought up PTUMD, which brought up the issue of minimum packet size.

Stateless rejects require the CHLO to fit into one packet, so the minimum should be specified with that in mind.

#64 also brought up the issue of downgrade attacks, and given the vast majority of paths permit 1200 bytes, we should be able to agree on a reasonable(ie: >1k) minimum size.

We need to define how the public flags might be extended, or if it could be. This has a pretty serious impact on #55.

In the Hybrid Slow Start section, there is a unicode character. Those are (still) verboten.

ECN is not currently mentioned in the recovery draft, but it should be included.

More importantly, the transport draft has no ability for the peer to communicate ECN marks back to the sender. I suspect, like ECN, the use of this in the transport would be negotiable in the QUIC handshake.

In practice, there most userspace network stacks also cannot see if those marks are set when packets are read.

... relative to the client's ClientHello.

We don't want to design a packet amplifier, but it's highly likely that the server's Certificate will cause the server's messages to be at least a little bigger than the initial messages from the client. We do need servers to send HelloRetryRequest and do source address validation, but how often?

The attacker needs to be on path to create a valid-looking unprotected packet.

Also, randomization doesn't help much if the attacker is on-path.