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

Commentary: Add a section about being careful with timing with respect to CID migration if you actually care about linkability . 
 Linkability across CID changes is in the common case so trivial that protocol features to defeat linkability through other means risk being useless . " Find CID y where delay < d between last packet for CID x and first packet for CID y on 2 - tuple { a , p } , given { x , a , p } " is an operation which requires zero additional state and a simple O(kn log n ) search for any large on - path ( passive surveillance ) device that 's halfway smart about keeping per - flow state -- i.e. , it 's basically a free operation , and its utility is baked into the physics of CIDs -- after all , this is what CIDs are for . The ease of this analysis can only be mitigated by increasing the size of the anonymity set : ensuring that for any given delay window d , a minimum number of CIDs x transition on any given { a , p } . This seems like good operational advice for servers with enough traffic to build such anonymity sets ( should they have interest in preventing client linkability , of course ) -- small servers are probably out of luck though . Applicability should call this out as a problem , manageability should suggest a solution space . 
 -quic - transport section 6.11.5 . begins to address this now , but aside from the following ... still seems to pretend that coordinated CID migration is sufficient to fix linkability . So I still think we need something in -applicability . Will throw together a PR today . 
 addressed in
Paragraph (version B):
QUIC provides for multiple Server and Client Connection IDs to be
used simultaneously by a given connection, which allows seamless
connection migration when one of the endpoints changes IP address
and/or UDP port.  Section 6.11.5 of QUIC describes how to use this
facility to reduce the risk of exposing a link among these addresses
to observers on the network.  However, analysis of the lifetimes of
six-tuples (source and destination addresses as well as the migrated
CID) may expose these links anyway.
Paragraph (version B):
In practice, a finite set of flows will be undergoing migration
within any one time window as seen from any given observation point
in the network, and any migration must keep at least one endpoint
address constant during the migration.  Because of this, a key
insight here is that this finite set of flows represents the
anonymity set for any one flow undergoing migration within it.  For
endpoints with low volume, this anonymity set will be necessarily
small, so there remains a significant risk of linkage exposure
through timing-based analysis.
Paragraph (version B):
The most efficient mitigation for these attacks is operational, by
increasing the size of the anonymity set as seen from a passive
observer in the Internet, either by using a load balancing
architecture that loads more flows onto a single server-side address,
by coordinating the timing of migrations to attempt to increase the
number of simultaneous migrations at a given time, or through other
means.
Draft: draft-ietf-quic-manageability

Commentary: also to address issue 
 Copying from There 's no requirement that servers use a particular UDP port for HTTP / QUIC or any other QUIC traffic . Using    , the server is able to pick and advertise any port number and a compliant client will handle it just fine . That 's already the case , and is n't part of this issue . updates the HTTP draft to highlight this , increasing the odds that implementations will test and support that case . This issue is to track that it might actually be desirable from a privacy standpoint for servers to pick arbitrary port numbers and perhaps even rotate them periodically ( though that requires coordination with their    advertisements and lifetimes , which could be challenging ) in order to make it more difficult for a network observer to classify traffic ( and therefore more difficult to ossify ) . On the other hand , as we 're wrestling with in each of these privacy / manageability debates , removing easy network visibility into the likely protocol by using arbitrary port numbers means that middleboxes will probably resort to other means of attempting to identify protocols and potentially doing it badly , which could result in even worse ossification . ( E.g. indexing into the TLS ClientHello to find the ALPN list , then panicking on a different handshake protocol . ) There 's further discussion on the original issue , but this belongs in the ops drafts , not the protocol drafts . 
 this kind - of - but - not - really - duplicates , which I 'll go ahead and close . 
 Actually , it 's an exact duplicate , given that it points to the same issue . ;-) My bad . 
 can you check if PR addresses this issue sufficiently ? At least for the applicability doc ... 
 Now also PR for the manageability statement . 
 and are a ( ready for -03 ) treatment of this ; however , we should consider if we want to say more , e.g. such as general guidance / recommendations for using ALPN in QUIC mappings , for instance ? Keeping this open to track . 
 created new issue for ALPN
Paragraph (version B):
Applications that have a mapping for TCP as well as QUIC are expected
to use the same port number for both services.  However, as with TCP-
based services, especially when application layer information is
encrypted, there is no guarantee that a specific application will use
the registered port, or the used port is carrying traffic belonging
to the respective registered service.  For example, QUIC-TRANSPORT
specifies the use of Alt-Svc for discovery of QUIC/HTTP services on
other ports.
Paragraph (version B):
Further, as QUIC has a connection ID, it is also possible to maintain
multiple QUIC connections over one 5-tuple.  However, if the
connection ID is not present in the packet header, all packets of the
5-tuple belong to the same QUIC connection.
Draft: draft-ietf-quic-applicability

Commentary: -- you mentioned wanting to have a more balanced view of zero RTT in the applicability draft : is this something like what you had in mind ? 
 I 'll go ahead and merge this to have one less editor 's note in the ietf-00 submission ; file an issue if this does n't address the " thinking in 0rtt " point adequately . 
  noted at the interim in Paris that we should point out that applications need to be re - thought slightly to get the benefits of zero RTT . Add a little text to discuss this and why it 's worth the effort , before we go straight into the dragons .
Paragraph (version A):
However, data in the frames contained in 0-RTT packets of a such a
connection must be treated specially by the application layer.
Replay of these packets can cause the data to processed twice.  This
is further described in HTTP-RETRY.
Paragraph (version A):
0-RTT data also does not benefit from perfect forward secrecy (PFS).
Paragraph (version B):
A transport protocol that provides 0-RTT connection establishment to
recently contacted servers is qualitatively different than one that
does not from the point of view of the application using it.
Relative tradeoffs between the cost of closing and reopening a
connection and trying to keep it open are different; see resumption-
v-keepalive.
Paragraph (version B):
Applications must be slightly rethought in order to make best use of
0-RTT resumption.  Most importantly, application operations must be
divided into idempotent and non-idempotent operations, as only
idempotent operations may appear in 0-RTT packets.  This implies that
the interface between the application and transport layer exposes
idempotence either ecplicitly or implicitly.
Paragraph (version B):
Retransmission or (malicious) replay of data contained in 0-RTT
resumption packets could cause the server side to receive two copies
of the same data.  This is further described in HTTP-RETRY.  Data
sent during 0-RTT resumption also cannot benefit from perfect forward
secrecy (PFS).
Paragraph (version B):
Data in the first flight sent by the client in a connection
established with 0-RTT MUST be idempotent.  Applications MUST be
designed, and their data MUST be framed, such that multiple reception
of idempotent data is recognized as such by the receiverApplications
that cannot treat data that may appear in a 0-RTT connection
establishment as idempotent MUST NOT use 0-RTT establishment.  For
this reason the QUIC transport SHOULD provide an interface for the
application to indicate if 0-RTT support is in general desired or a
way to indicate whether data is idempotent, and/or whether PFS is a
hard requirement for the application.