jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-quic-tls

Commentary: The current text was unclear to me : how does one enforce a MUST on TLS ? The updated text hopefully clarifies that it 's legal for a server to send a NewSessionTicket without the " early_data " extension - that indicates that the server supports resumption but not 0 - RTT , as it does in TLS .
Paragraph (version A):
In order to be usable for 0-RTT, TLS MUST provide a NewSessionTicket
message that contains the "early_data" extension with a
max_early_data_size of 0xffffffff; the amount of data which the
client can send in 0-RTT is controlled by the "initial_max_data"
transport parameter supplied by the server.  A client MUST treat
receipt of a NewSessionTicket that contains an "early_data" extension
with any other value as a connection error of type
PROTOCOL_VIOLATION.
Paragraph (version B):
To communicate their willingness to process 0-RTT data, servers send
a NewSessionTicket message that contains the "early_data" extension
with a max_early_data_size of 0xffffffff; the amount of data which
the client can send in 0-RTT is controlled by the "initial_max_data"
transport parameter supplied by the server.  Servers MUST NOT send
the "early_data" extension with a max_early_data_size set to any
value other than 0xffffffff.  A client MUST treat receipt of a
NewSessionTicket that contains an "early_data" extension with any
other value as a connection error of type PROTOCOL_VIOLATION.
Draft: draft-ietf-quic-transport

Commentary: It can result in an inflated RTT , as well as being a waste of bytes . 
 Even though a sender is encouraged to assemble frames containing up - to - date information every time it sends a packet , it is not forbidden to retransmit copies of frames from lost packets . A receiver MUST accept packets containing an outdated frame , such as a MAX_DATA frame carrying a smaller maximum data than one found in an older packet . If a packet containing an ACK is lost and the payload is retransmitted with a new packet number AND no ACKs are received prior to the retransmitted ACK frame arriving , the peer will calculate and RTT sample that is 2 RTTs + loss recovery delay . As such , I 'd suggest we add a warning that retransmitting ACKs can cause RTT inflation and is heavily discouraged . There may be other issues with retransmitting ACKs , but this is the first that comes to mind .
Paragraph (version A):
The most recent set of acknowledgments are sent in ACK frames.  An
ACK frame SHOULD contain all unacknowledged acknowledgments, as
described in sending-acknowledgements.
Paragraph (version B):
ACK frames carry the most recent set of acknowledgements and the
Ack Delay from the largest acknowledged packet, as described in
sending-acknowledgements.  Delaying the transmission of packets
containing ACK frames or sending old ACK frames can cause the peer
to generate an inflated RTT sample or unnecessarily disable ECN.
Draft: draft-ietf-quic-tls

Commentary: Add short explanation and reference to explain why QUIC - TLS bans the use of post - handshake client authentication . 
 draft - tls section 4.4 ( Peer Authentication ) states : This sounds like there are security implications , but what they are is unclear . As a reader of the document , this makes me doubt my understanding of the protocol . If we do n't have a good justification for banning this , we should n't be banning it . ( This is me reopening since that was closed for being a question . ) 
 Is the text unclear , or are you asking to re - enable post - handshake authentication ? 
 At least I am curious about the reasoning behind this , not that I am against it . 
 The best way to understand the rationale is to try to work through how a particular protocol might use this feature . Read , look at the design and discussion and see the sorts of problems it tries to address . In that case , some of the problems are with server - authentication , which you can safely ignore , but the general class of problems related to concurrency and how that relates to the status of authentication produce a fairly complex design . Now I might concede that it is possible to build a protocol that uses this TLS feature well , but I would still hold that are a far superior design . 
 Thanks for the explantion and pointers . On exported authenticators I guess there is some overlap with  ,  , and temporary web service tokens once you get past the handshake . 
 if we have a good reason ( which it sounds like we do ) , then this issue tracks adding that reason to the draft . 
 Now that has clearly written this up , perhaps we can resolve this issue by adding a reference to in draft - ietf - quic - tls . If that sounds good to the editors I can write a PR . 
 I 'd prefer more direct text . You get references to HTTP/2 doc and that in turn references TLS 1.2 with compression rules etc . that needs to be filtered out . 
 : that sounds like a good way forward . 
 I 'm going to say that this is editorial - enough to just merge . MUST NOT implies PROTOCOL_VIOLATION , so the new normative language is fine as editorial . I 'll give others a chance to disagree though .
Paragraph (version A):
A server MUST NOT use post-handshake client authentication (see
Section 4.6.2 of TLS13).
Paragraph (version B):
A server MUST NOT use post-handshake client authentication (as
defined in Section 4.6.2 of TLS13), because the multiplexing offered
by QUIC prevents clients from correlating the certificate request
with the application-level event that triggered it (see HTTP2-TLS13).
More specifically, servers MUST NOT send post-handshake TLS
CertificateRequest messages and clients MUST treat receipt of such
messages as a connection error of type PROTOCOL_VIOLATION.
Draft: draft-ietf-quic-tls

Commentary: This is a point makes in , but it probably pays to make it more clearly . This was possible in earlier iterations of the draft , so it 's worth stamping out residual mentions . 
 Section 4.5 of quic - tls : Early data within the TLS connection MUST NOT be used . As it is for other TLS application data , a server MUST treat receiving early data on the TLS connection as a connection error of type PROTOCOL_VIOLATION . As there is no way to express TLS application data ( no record headers ! ) I believe there is no way for the proposed error condition to occur . I propose we strike the paragraph , though we might mention that this condition is impossible for clarity .
Paragraph (version A):
At any given time, the TLS stack at an endpoint will have a current
sending encryption level and receiving encryption level.  Each
encryption level is associated with a different flow of bytes, which
is reliably transmitted to the peer in CRYPTO frames.  When TLS
provides handshake bytes to be sent, they are appended to the current
flow and any packet that includes the CRYPTO frame is protected using
keys from the corresponding encryption level.
Paragraph (version B):
At any time, the TLS stack at an endpoint will have a current sending
encryption level and receiving encryption level.  Each encryption
level is associated with a different flow of bytes, which is reliably
transmitted to the peer in CRYPTO frames.  When TLS provides
handshake bytes to be sent, they are appended to the current flow and
any packet that includes the CRYPTO frame is protected using keys
from the corresponding encryption level.
Paragraph (version B):
QUIC is only capable of conveying TLS handshake records in CRYPTO
frames.  TLS alerts are turned into QUIC CONNECTION_CLOSE error
codes; see tls-errors.  TLS application data and other message types
cannot be carried by QUIC at any encryption level and is an error if
they are received from the TLS stack.
Paragraph (version A):
Early data within the TLS connection MUST NOT be used.  As it is for
other TLS application data, a server MUST treat receiving early data
on the TLS connection as a connection error of type
PROTOCOL_VIOLATION.
Draft: draft-ietf-quic-transport

Commentary: At the top of page 66 of the , we read : The second sentence seems to imply that a field could be omitted . Does this sentence sound odd to anyone else ? 
 While it is perhaps technically redundant , I think it is actually quite helpful . The first sentence says , " complete " but that might be open to interpretation . The second sentence makes it clear what that means . I like it . YMMV :) 
 My issue is not with the redundancy of the second senteance , but rather with its meaning . The specification that " no fields be omitted " implies that fields could be omitted -- but they ca n't be : There are no optional fields in packet headers . 
 Maybe change the second sentence to something like : 
 writes : The third sentence clarifies the first sentence well , too . I would just drop the second sentence altogether . 
 I ca n't remember now , but we did have an intermediate design where redundant fields were absent . This sentence may have crept in around then . I agree with : it does seem redundant now .
Paragraph (version A):
Every QUIC packet that is coalesced into a single UDP datagram is
separate and complete.  Though the values of some fields in the
packet header might be redundant, no fields are omitted.  The
receiver of coalesced QUIC packets MUST individually process each
QUIC packet and separately acknowledge them, as if they were received
as the payload of different UDP datagrams.  For example, if
decryption fails (because the keys are not available or any other
reason), the receiver MAY either discard or buffer the packet for
later processing and MUST attempt to process the remaining packets.
Paragraph (version B):
Every QUIC packet that is coalesced into a single UDP datagram is
separate and complete.  The receiver of coalesced QUIC packets MUST
individually process each QUIC packet and separately acknowledge
them, as if they were received as the payload of different UDP
datagrams.  For example, if decryption fails (because the keys are
not available or any other reason), the receiver MAY either discard
or buffer the packet for later processing and MUST attempt to process
the remaining packets.
Draft: draft-ietf-quic-tls

Commentary: This paper studies several " nonce hiding " transformations , of which the QUIC header protection algorithm is one . This change replaces the old analysis text with something a bit more crisp . 
 I 'm really happy to see good research on this that confirms our intuitions about one of the most important QUIC - specific constructions . Thanks for doing this  . Are you planning to make a similar contribution to DTLS 1.3 ? 
 My pleasure . :-) Yep !
Paragraph (version A):
Header protection relies on the packet protection AEAD being a
pseudorandom function (PRF), which is not a property that AEAD
algorithms guarantee.  Therefore, no strong assurances about the
general security of this mechanism can be shown in the general case.
The AEAD algorithms described in this document are assumed to be
PRFs.
Paragraph (version A):
This construction is secure against chosen plaintext attacks (IND-
CPA) IMC.
Paragraph (version B):
The header protection variants in this document use a pseudorandom
permutation (PRP) in place of a generic PRF.  However, since all PRPs
are also PRFs IMC, these variants do not deviate from the HN1
construction.
Paragraph (version B):
As "hp_key" is distinct from the packet protection key, it follows
that header protection achieves AE2 security as defined in NAN and
therefore guarantees privacy of "field", the protected packet header.
Future header protection variants based on this construction MUST use
a PRF to ensure equivalent security guarantees.
Draft: draft-ietf-quic-qpack

Commentary: with some text in the TBD Security Considerations section . 
 If I understand correctly , the decoder stream buffer which endpoint has to keep grows indefinitely if encoder - side app does not return back flow control credit . The number of Header Acknowledgement instruction is bounded by the number of  blocked streams which decoder can specify . On the other hand , the number of Stream Cancellation is not bounded . So if encoder - side app keeps resetting stream without sending MAXSTREAMDATA , decoder - side has to keep all closed stream in decoder stream . I 'm not sure this has been discussed already . 
 The solution to this seems implementation - dependent , but implementations should place a bound on the amount of data waiting to be sent on the decoder stream . 
  , this limit would create a way to force the peer to kill the connection by starving the decoder stream of flow control credit and then cancelling lots of streams . However , the consumer of ( and therefore the entity which could fail to read ) the decoder stream is the encoder , and the encoder can trivially cause the connection to close by emitting an invalid instruction anyway . That seems fine . 
 writes : This is incorrect : an for each header that references the dynamic table .
Paragraph (version B):
While the negotiated limit on the dynamic table size accounts for
much of the memory that can be consumed by a QPACK implementation,
data which cannot be immediately sent due to flow control is not
affected by this limit.  Implementations should limit the size of
unsent data, especially on the decoder stream where flexibility to
choose what to send is limited.  Possible responses to an excess of
unsent data might include limiting the ability of the peer to open
new streams, reading only from the encoder stream, or closing the
connection.
Draft: draft-ietf-quic-http

Commentary: by saying that , since error codes are extensible , you ca n't treat the receipt of an error code you do n't understand or do n't think you should have gotten as an error itself . ( Though it can still be an error that the stream closed , regardless of the error code . ) ( Which leads to the question , should we be greasing the error code space ? ) 
 Yes ! I would create a grease stream and it could be closed ( stop sending and/or reset ) by peers . 
 That seems to have very narrow applicability . Would you only be permitted to send a greasing error code in that case ? Or to put the question differently , what would happen if you decided to randomly turn a subset of the semantic - ful error codes you generate into greasing codes ? 
 Per the language of this PR , I think that would be fine . Possibly with the exception of the errors that are supposed to inform behavior , like REJECTED and perhaps EARLYRESPONSE . 
 The HTTP/3 spec is a little light on detail about processing an error code that should have never been sent . At suggestion , this issue is scoped to discussion of HTTP/3 stream errors : Example a ) a client receives a STOPSENDING with HTTPREQUESTCANCELLED Example b ) a server receives a RESETSTREAM with HTTPLIMIT_EXCEEDED 
 I 'm mostly inclined to treat this with the same fatalism as an invalid code in an APPLICATIONCLOSE code that makes no sense . The stream is gone , regardless of the error code . If it was a critical stream , then CLOSEDCRITICALSTREAM ; otherwise , perhaps a MAY GENERALPROTOCOL_ERROR ? 
 I agree with The error code does n't matter . What matters is how you handle it . Error codes with no specific handling are fine ; error codes with special handling can be ignored . The question of what to do with critical streams is separable . Do n't make things worse by coupling the two concepts . 
 Oh , totally separable . But then you 'd then have two competing permissions - to - blow up -- because the critical stream close ( regardless of error code ) and because a stream closed with an invalid error code ( regardless of which stream ) . And I do n't think it matters which reason you have to blow up or what the resulting error is .
Paragraph (version B):
Because new error codes can be defined without negotiation (see
extensions), receipt of an unknown error code or use of an error code
in an unexpected context MUST NOT be treated as an error.  However,
closing a stream can constitute an error regardless of the error code
(see request-response).
Draft: draft-ietf-quic-tls

Commentary: a TLS stack . The canonical example being the Handshake keys , which are needed by a client to acknowledge partial server Handshake flights . TLS wo n't use those keys itself until it has the entire set of Handshake messages from the server . In doing this , I decided that it makes sense to reorder the sequence diagram to show what incoming packets trigger different events . 
 In order for the client to be able to acknowledge packets sent with Handshake encryption level , it needs to have access to the Handshake write key right after processing the ServerHello . states that the Handshake write key is exported after receiving the server 's Finished message , which would make loss recovery of Handshake packets impossible . I found this fact non - obvious , and I think it should be documented in some way that we 're deviating from the schedule in which a normal TLS 1.3 implementation would make new keys available . 
 I had the same realization a while ago , but failed to capture that in the spec . It 's a fairly important point that - if ignored - would lead to bad outcomes , because a good part of the time you can get away with not exporting it early . You mostly just get transient errors ... until the server ca n't fit its certificate into 3 packets , then you get a hard fail .
Paragraph (version A):
As keys for new encryption levels become available, TLS provides QUIC
with those keys.  Separately, as TLS starts using keys at a given
encryption level, TLS indicates to QUIC that it is now reading or
writing with keys at that encryption level.  These events are not
asynchronous; they always occur immediately after TLS is provided
with new handshake bytes, or after TLS produces handshake bytes.
Paragraph (version B):
As keys for new encryption levels become available, TLS provides QUIC
with those keys.  Separately, as keys at a given encryption level
become available to TLS, TLS indicates to QUIC that reading or
writing keys at that encryption level are available.  These events
are not asynchronous; they always occur immediately after TLS is
provided with new handshake bytes, or after TLS produces handshake
bytes.
Paragraph (version B):
QUIC also needs access to keys that might not ordinarily be available
to a TLS implementation.  For instance, a client might need to
acknowledge Handshake packets before it is ready to send CRYPTO
frames at that encryption level.  TLS therefore needs to provide keys
to QUIC before it might produce them for its own use.
Paragraph (version B):
exchange-summary shows the multiple packets that form a single
"flight" of messages being processed individually, to show what
incoming messages trigger different actions.  New handshake messages
are requested after all incoming packets have been processed.  This
process might vary depending on how QUIC implementations and the
packets they receive are structured.
Draft: draft-ietf-quic-invariants

Commentary: Invariants text was unclear on where the Destination Connection ID field was and how big it could be . 
 Section 4.2 of the Invariant Short header are not explicit that the Destionation CID follows the first byte : " A QUIC packet with a short header includes a Destination Connection ID . The short header does not include the Connection ID Lengths , Source Connection ID , or Version fields . " As see it just says that the destination CID is part of the short header , not where to find it . 
 Also the length of the DCID in the short header is unclear . With the long header 's restriction on both source and destination CID I do n't think the CID is of arbitrary length as stated in Section 4.3 . I think it is 0 to 18 bytes long as set agreed by the connection . 
 Yes , DCID follows the first octet , and we should say that . As for the length , 0/4 - 18 is a restriction that we agreed applies only to long headers . You can - if the QUIC version allows it - negotiate other lengths for connection IDs using other methods . 
 Ok , the spec is in some sense clear that this can be of arbitary length . However , that this is not required to be consistent with the long header is far from obvious and probably should be explicitly remarked . An realization I did n't have before over this design is that a given destination IP address and UDP port that deals with multiple QUIC connections will be foreced to use one commond DCID length across all QUIC connections using that port , otherwise it will have to use prefixes for DCIDs to be able to determine how long the actual DCID field are to enable decoding the header protection . It might have been a misstake to not include an DCID length field . 
 The endpoint can decide on its own DCID length encoding , so that is fine . 
 One editorial suggestion , but LG
Paragraph (version A):
A QUIC packet with a short header includes a Destination Connection
ID.  The short header does not include the Connection ID Lengths,
Source Connection ID, or Version fields.
Paragraph (version B):
A QUIC packet with a short header includes a Destination Connection
ID immediately following the first byte.  The short header does not
include the Connection ID Lengths, Source Connection ID, or Version
fields.  The length of the Destination Connection ID is not specified
in packets with a short header and is not constrained by this
specification.
Draft: draft-ietf-quic-transport

Commentary: They do n't have a length field , so the only place they could go is at the end of a packet . As the spec currently stands , it 's valid to send a packet like this . There 's little value in doing that . Do we want to continue to allow this ? 
 My understanding is that they are implicitly forbidden , because coalescing packets belonging to different connections are forbidden , and because there ’s nothing to coalesce with when either of the two types of the packets is sent . I am not sure if we need to be more clear on that , considering the fact we generally use MAY for the discarding rules for coalesced packets . 
 VN certainly causes a new connection based on discussions in Tokyo . Retry does not cause a new connection(ie : same ClientHello ) . Clarifying this seems wise if it 's not already clear . 
 Yes , however when a Retry packet is being sent , there 's nothing a server can send along with . Regarding if we need to clarify , while I do not think it 's absolutely necessary , I can see that people might want to have it stated considering the fact that we do utilize corner case rules of coalesced packets ( see ) . 
 So , is this editorial ? 
 I 'm with but I 'm still wondering : what is the clarification that we can provide ? 
 Simply clarifying that " VN and Retry packets will never be coalesced " as part of the changes we would make in might be a good idea . We do not need to use a RFC 2119 word here due to the editorial nature of the issue .
Paragraph (version A):
Retry packets (packet-retry), Version Negotiation packets (packet-
version), and packets with a short header (short-header) do not
contain a Length field and so cannot be followed by other packets in
the same UDP datagram.
Paragraph (version B):
Retry packets (packet-retry), Version Negotiation packets (packet-
version), and packets with a short header (short-header) do not
contain a Length field and so cannot be followed by other packets in
the same UDP datagram.  Note also that there is no situation where a
Retry or Version Negotiation packet is coalesced with another packet.