jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-tls-dtls-connection-id

Commentary: As suggested by   , mention that the new ciphertext record format provides ContentType encryption and per - record padding in both abstract and introduction . 
 Update from Éric re : Section 6 
 About " -- Section 3 -- , DTLS / zero - length CID " " An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello . " The " zero - length CID " therefore is mainly used for the very common cases , where only the clients are required to send such a CID , but not the server . Maybe adding a hint to   will help ? 
 About " -- Section 6 -- " Yes , that 's still very complex : First , processing the record seems to be easier ( less restricted ) , than use a changed source address for sending data back . Using a changed source address for sending data back to , is not generally solved . There are some special case , e.g. , if the data sent back is very small , there is no risk ( at least , none has explained one ) . There may also be some upper - layer mechanisms , which helps out ( e.g. for coap ) . And there is a idea of a general solution , but that will require more time . Because of the required time , the idea was to release this spec without RRC and postpone that general work ( see also issue ) . 
 also in the abstract ? Some initial attempt at this in 
 LGTM
Mailing list commentary: has entered the following ballot position for draft - ietf - tls - dtls - connection - id-11 : No Objection When responding , please keep the subject line intact and reply to all email addresses included in the To and CC lines . ( Feel free to cut this introductory paragraph , however . ) Please refer to for more information about DISCUSS and COMMENT positions . The document , along with other ballot positions , can be found here :
Paragraph (version B):
The new ciphertext record format with CID also provides content type
encryption and record-layer padding.
Paragraph (version B):
Adding a CID to the ciphertext record format presents an opportunity
to make other changes to the record format.  In keeping with the best
practices established by TLS 1.3, the type of the record is
encrypted, and a mechanism provided for adding padding to obfuscate
the plaintext length.
Draft: draft-ietf-tls-dtls-connection-id

Commentary: attempt at addressing  's concern about the use of " globally " 
 You 're right , the " globally " seems to be used in the sense of a " programming language " , so the scope is a peer and the CID emitted by this peer for other peers to be used , when the other peers sends records to the emitting peer . Maybe we find a better term than " globally " to describe that . 
 maybe " sitewide " ?
Paragraph (version A):
Because each party sends the value in the "connection_id" extension
it wants to receive as a CID in encrypted records, it is possible for
an endpoint to use a globally constant length for such connection
identifiers.  This can in turn ease parsing and connection lookup,
for example by having the length in question be a compile-time
constant.  Such implementations MUST still be able to send CIDs of
different length to other parties.  Since the CID length information
is not included in the record itself, implementations that want to
use variable-length CIDs are responsible for constructing the CID in
such a way that its length can be determined on reception.
Paragraph (version B):
Because each party sends the value in the "connection_id" extension
it wants to receive as a CID in encrypted records, it is possible for
an endpoint to use a deployment-specific constant length for such
connection identifiers.  This can in turn ease parsing and connection
lookup, for example by having the length in question be a compile-
time constant.  Such implementations MUST still be able to send CIDs
of different length to other parties.  Since the CID length
information is not included in the record itself, implementations
that want to use variable-length CIDs are responsible for
constructing the CID in such a way that its length can be determined
on reception.
Draft: draft-ietf-tls-dtls-connection-id

Commentary: Partly addresses 
 Regarding : We could streamline that a bit : the affiliations ( who knows which have become stale in the meantime ? ) , and also Besides , is " task force " the right term ? Would " QUIC CID design team " be a better designation ?
Mailing list commentary: has entered the following ballot position for draft - ietf - tls - dtls - connection - id-11 : No Objection When responding , please keep the subject line intact and reply to all email addresses included in the To and CC lines . ( Feel free to cut this introductory paragraph , however . ) Please refer to for more information about DISCUSS and COMMENT positions . The document , along with other ballot positions , can be found here :
Paragraph (version A):
Because each party sends the value in the "connection_id" extension
it wants to receive as a CID in encrypted records, it is possible for
an endpoint to use a globally constant length for such connection
identifiers.  This can in turn ease parsing and connection lookup,
for example by having the length in question be a compile-time
constant.  Such implementations MUST still be able to send CIDs of
different length to other parties.  Implementations that want to use
variable-length CIDs are responsible for constructing the CID in such
a way that its length can be determined on reception.  Note that
there is no CID length information included in the record itself.
Paragraph (version B):
Because each party sends the value in the "connection_id" extension
it wants to receive as a CID in encrypted records, it is possible for
an endpoint to use a globally constant length for such connection
identifiers.  This can in turn ease parsing and connection lookup,
for example by having the length in question be a compile-time
constant.  Such implementations MUST still be able to send CIDs of
different length to other parties.  Since the CID length information
is not included in the record itself, implementations that want to
use variable-length CIDs are responsible for constructing the CID in
such a way that its length can be determined on reception.
Draft: draft-ietf-tls-dtls-connection-id

Commentary: It is a new record format ; the new type is the CID content type mentioned shortly thereafter .
Paragraph (version A):
If DTLS peers have negotiated the use of a non-zero-length CID for a
given direction, then once encryption is enabled they MUST send with
the record format defined in dtls-ciphertext with the new MAC
computation defined in mac and the content type tls12_cid.  Plaintext
payloads never use the new record type and the CID content type.
Paragraph (version B):
If DTLS peers have negotiated the use of a non-zero-length CID for a
given direction, then once encryption is enabled they MUST send with
the record format defined in dtls-ciphertext with the new MAC
computation defined in mac and the content type tls12_cid.  Plaintext
payloads never use the new record format or the CID content type.
Draft: draft-ietf-tls-dtls-connection-id

Commentary: Suggest a column name . Deprecate the old connection_id codepoint . 
 We currently have an early allocation of the TLS extensiontype codepoint 53 that was allocated on 2019 - 07 - 02 . An implementation of the draft at that time will no longer interoperate with the current specification due to changes in how the MAC inputs and AAD are laid out . If we want to allocate a new extensiontype value for the new semantics , we should tell IANA that there is an existing early allocation and , e.g. , that it should be left to expire ( and what version of the draft to use as a reference until it does ) , with a new codepoint to be allocated in its stead . We also have the option to direct IANA that " once this document is approved for publication , the early allocation will be deprecated and the following assignment will be made " . 
 I think we should take your last option . 
 See suggestion inline , though even as - is this is probably enough to cause the right things to happen at IANA and the RPC .
Paragraph (version A):
IANA is requested to add an extra column to the "TLS ExtensionType
Values" registry to indicate whether an extension is only applicable
to DTLS and to include this document as an additional reference for
the registry.
Paragraph (version A):
IANA is requested to allocate an entry to the existing "TLS
ExtensionType Values" registry, for connection_id(TBD1) as described
in the table below.
Paragraph (version B):
IANA is requested to add an extra column named "DTLS-Only" to the
"TLS ExtensionType Values" registry to indicate whether an extension
is only applicable to DTLS and to include this document as an
additional reference for the registry.
Paragraph (version B):
IANA is requested to allocate an entry to the existing "TLS
ExtensionType Values" registry, for connection_id(TBD1) as described
in the table below.  Although the value 53 has been allocated by
early allocation for a previous version of this document, it is
incompatible with this document.  Once this document is approved for
publication, the early allocation will be deprecated in favor of this
assignment.
Draft: draft-ietf-tls-dtls-connection-id

Commentary: I cleaned this up a bit , PTAL . 
 Updates look good . Thanks !
Paragraph (version A):
If DTLS peers have not negotiated the use of CIDs, which includes the
case where both sent a zero-length cid in their connection_id
extensions, then the RFC 6347-defined record format and content type
MUST be used.
Paragraph (version A):
If DTLS peers have negotiated the use of a non-zero-length CID in at
least one direction using the ClientHello and the ServerHello
messages, then the peers need to take the following steps.
Paragraph (version A):
The DTLS peers determine whether incoming or outgoing (or both)
messages need to use the new record format, i.e., the record format
containing the CID.  The new record format with the the tls12_cid
content type is only used once encryption is enabled.  Plaintext
payloads never use the new record type and the CID content type.
Paragraph (version A):
For sending, if a zero-length CID has been negotiated then the RFC
6347-defined record format and content type MUST be used (see
Section 4.1 of RFC6347) else the new record layer format with the
tls12_cid content type defined in dtls-ciphertext MUST be used.
Paragraph (version A):
When transmitting a datagram with the tls12_cid content type, the new
MAC computation defined in mac MUST be used.
Paragraph (version A):
For receiving, if the tls12_cid content type is set, then the CID is
used to look up the connection and the security association.  If the
tls12_cid content type is not set, then the connection and security
association is looked up by the 5-tuple and a check MUST be made to
determine whether the expected CID value is indeed zero length.  If
the check fails, then the datagram MUST be dropped.
Paragraph (version B):
If DTLS peers have not negotiated the use of CIDs, or a zero-length
CID has been advertised for a given direction, then the RFC
6347-defined record format and content type MUST be used to send in
the indicated direction(s).
Paragraph (version B):
If DTLS peers have negotiated the use of a non-zero-length CID for a
given direction, then once encryption is enabled they MUST send with
the record format defined in dtls-ciphertext with the new MAC
computation defined in mac and the content type tls12_cid.  Plaintext
payloads never use the new record type and the CID content type.
Paragraph (version B):
When receiving, if the tls12_cid content type is set, then the CID is
used to look up the connection and the security association.  If the
tls12_cid content type is not set, then the connection and security
association is looked up by the 5-tuple and a check MUST be made to
determine whether a non-zero length CID is expected.  If a non-zero-
length CID is expected for the retrieved association, then the
datagram MUST be treated as invalid, as described in Section 4.1.2.1
of RFC6347.
Draft: draft-ietf-tls-dtls-connection-id

Commentary:    secdir review :
Mailing list commentary: Reviewer : Review result : Ready I am the assigned Gen - ART reviewer for this draft . The General Area Review Team ( Gen - ART ) reviews all IETF documents being processed by the IESG for the IETF Chair . Please treat these comments just like any other last call comments . For more information , please see the FAQ at . Document : draft - ietf - tls - dtls - connection - id-10 Reviewer : Review Date : 2021 - 03 - 15 IETF LC End Date : 2021 - 03 - 28 IESG Telechat date : Unknown Summary :   Concerns : None . Minor Concerns : None . Nits : Section 4 : For increased clarity , I suggest : OLD : realtype The content type describing the payload . NEW : realtype The content type describing the cleartext payload .
Paragraph (version A):
The content type describing the payload.
Paragraph (version B):
The content type describing the cleartext payload.
Draft: draft-ietf-tls-dtls-connection-id

Commentary:    review :
Mailing list commentary: Some editorial quirks s.2 lacks the boiler plate of s.3 I found this unclear until I had understood it all ( or perhaps I do not understand it ) " ... or again , alternately , to use a zero - length CID ) . " This suggests that a zero length CID is valid in Application Data which later text seems to contradict ; otherwise I can not see what this is saying . " If DTLS peers have negotiated the use of a CIDs using the ClientHello and the ServerHello messages " arguably sending a zero CID and receiving a zero CID is a successful Hello negotiation perhaps " If DTLS peers have negotiated the use of a non - zero CID in at least one direction , using the ClientHello and the ServerHello messages " " The DTLS peers determine whether incoming and outgoing messages need .. " seems not to cater for unidirectional CIDs ; perhaps " The DTLS peers determine whether incoming or outgoing , or both , messages need .. " s.4 /always recieve CIDs / always receive CIDs/ s.5.1 " the with - then - MAC processing described in [ RFC7366 ] . " I do not understand why ' with ' is needed s.5.2 ditto s.8 /this aspects SHOULD refuse / these aspects SHOULD refuse/ s.10 I would find this clearer as three sections for the three IANA actions 10.1 new column for ExtensionType 10.2 new value for ExtensionType 10.3 new value for ContentType " IANA is requested to allocate an entry to the existing TLS " ExtensionType Values " registry , defined in [ , .. " well no ; whatever you think of RFC8447 the name has changed " IANA is requested to allocate an entry to the existing " TLS ExtensionType Values " registry , defined in [ , .. " or , if you are picky ( which I am not ) , IANA is requested to allocate an entry to the existing " TLS " ExtensionType Values " registry , defined in [ , and renamed by RFC8447 An extra column is but I can not see what value should be placed in that column for existing entries . " The tls12_cid ContentType is only applicable to DTLS 1.2 . " Good information but I struggle to see what IANA will do with it ; I see nowhere for it to go .
Paragraph (version A):
IANA is requested to allocate an entry to the existing TLS
"ExtensionType Values" registry, defined in RFC5246, for
connection_id(TBD1) as described in the table below.  IANA is
requested to add an extra column to the TLS ExtensionType Values
registry to indicate whether an extension is only applicable to DTLS
and to include this document as an additional reference for the
registry.
Paragraph (version B):
This document requests three actions by IANA.
Paragraph (version B):
IANA is requested to add an extra column to the "TLS ExtensionType
Values" registry to indicate whether an extension is only applicable
to DTLS and to include this document as an additional reference for
the registry.
Paragraph (version B):
IANA is requested to allocate an entry to the existing "TLS
ExtensionType Values" registry, for connection_id(TBD1) as described
in the table below.
Draft: draft-ietf-tls-dtls-connection-id

Commentary: Done . 
 This seems fine . Thanks ! Can you please resolve conflicts ?
Paragraph (version A):
There is a strategy for ensuring that the new peer address is able
to receive and process DTLS records.  No such test is defined in
this specification.
Paragraph (version B):
There is a strategy for ensuring that the new peer address is able
to receive and process DTLS records.  No such strategy is defined
in this specification.
Paragraph (version A):
An on-path adversary can create reflection attacks against third
parties because a DTLS peer has no means to distinguish a genuine
address update event (for example, due to a NAT rebinding) from one
that is malicious.  This attack is of particular concern when the
request is small and the response large.  See peer-address-update for
the strategy to ensure that the new peer address is able to receive
and process DTLS records.
Paragraph (version B):
An on-path adversary can create reflection attacks against third
parties because a DTLS peer has no means to distinguish a genuine
address update event (for example, due to a NAT rebinding) from one
that is malicious.  This attack is of particular concern when the
request is small and the response large.  See peer-address-update for
more on address updates.
Draft: draft-ietf-tls-dtls-connection-id

Commentary: Looks good to merge . 
 LGTM
Paragraph (version A):
With multi-homing, a passive attacker is able to correlate the
communication interaction over the two paths and the sequence number
makes it possible to correlate packets across CID changes.  The lack
of a CID update mechanism in DTLS 1.2 makes this extension unsuitable
for mobility scenarios where correlation must be considered.
Deployments that use DTLS in multi-homing environments and are
concerned about this aspects SHOULD refuse to use CIDs in DTLS 1.2
and switch to DTLS 1.3 where a CID update mechanism is provided and
sequence number encryption is available.
Paragraph (version B):
With multi-homing, a passive attacker is able to correlate the
communication interaction over the two paths.  The lack of a CID
update mechanism in DTLS 1.2 makes this extension unsuitable for
mobility scenarios where correlation must be considered.  Deployments
that use DTLS in multi-homing environments and are concerned about
this aspects SHOULD refuse to use CIDs in DTLS 1.2 and switch to DTLS
encryption is available.
Draft: draft-ietf-tls-dtls-connection-id

Commentary: Pending approval , too .
Paragraph (version A):
The extension_data field of this extension, when included in the
ClientHello, MUST contain the ConnectionId structure.  This structure
contains the CID value the client wishes the server to use when
sending messages to the client.  A zero-length CID value indicates
that the client is prepared to send with a CID but does not wish the
server to use one when sending.  Alternatively, this can be
interpreted as the client wishes the server to use a zero-length CID;
the result is the same.
Paragraph (version B):
The extension_data field of this extension, when included in the
ClientHello, MUST contain the ConnectionId structure.  This structure
contains the CID value the client wishes the server to use when
sending messages to the client.  A zero-length CID value indicates
that the client is prepared to send with a CID but does not wish the
server to use one when sending.
Draft: draft-ietf-tls-dtls-connection-id

Commentary: ... IANA consideration section based on issue raised by Sean ( see ) ... Security consideration section based on issue raised by  ( see ) 
 This PR aims to replace PR & PR 
 A couple of tweaks are needed for the IANA Considerations Section : Based on input from the IANA TLS DEs , it seems like we need a column to the TLS ExtensionType Values registry to indicate that an extension is DTLS - only . The column values for TLS 1.3 and Recommended are missing . Suggest blank for TLS 1.3 and N for Recommended . Add a note to say that connectionid is  only . Add instructions for IANA to assign " Y " to DTLS - okay column for tls12cid content type . 
 That results in " DTLS only " for TLS extensions and " DTLS - OK " for TLS parameters . I 'm not sure , if that just represents more the " current " usage than the " logic " behind it . I would be afraid , that this will hold up other ideas , which does n't match that " only for extensions / ok for parameters " pattern . 
 I am not sure what " DTLS - OK " for TLS parameters means 
 For TLS parameters there 's a column " DTLS - OK " , And for TLS extensions a column " DTLS only " . Does this explain my comment ? 
 We text to the draft - ietf - tls - dtls - connection - id-06 about the IANA consideration section . I believe this issue is closed .
Paragraph (version B):
An on-path adversary can also black-hole traffic or create a
reflection attack against third parties because a DTLS peer has no
means to distinguish a genuine address update event (for example, due
to a NAT rebinding) from one that is malicious.  This attack is of
concern when there is a large asymmetry of request/response message
sizes.
Paragraph (version A):
IANA is requested to allocate an entry to the existing TLS
"ExtensionType Values" registry, defined in RFC5246, for
connection_id(TBD1) defined in this document.
Paragraph (version B):
IANA is requested to allocate an entry to the existing TLS
"ExtensionType Values" registry, defined in RFC5246, for
connection_id(TBD1) as described in the table below.  IANA is
requested to add an extra column to the TLS ExtensionType Values
registry to indicate whether an extension is only applicable to DTLS.
Paragraph (version B):
Note: The value "N" in the Recommended column is set because this
extension is intended only for specific use cases.  This document
describes an extension for DTLS 1.2 only; it is not to TLS (1.3).
The DTLS 1.3 functionality is described in I-D.ietf-tls-dtls13.
Draft: draft-ietf-tls-dtls-connection-id

Commentary: If this PR is postponed to that date ( 12 . April ) , may be the final values could be used .
Mailing list commentary: We have received a request for early code - point assignment of values for draft - ietf - tls - dtls - connection - id-04 . We believe that only editorial changes are pending . Please respond to this list of you have concerns about these assignments by April 12 , 2019 . Thanks , , Sean and
Paragraph (version A):
The outer content type of a DTLSCiphertext record carrying a CID
is always set to the value 25 (tls12_cid).  The actual content
type of the record is found in DTLSInnerPlaintext.real_type after
decryption.
Paragraph (version B):
The outer content type of a DTLSCiphertext record carrying a CID
is always set to tls12_cid(TBD2).  The real content type of the
record is found in DTLSInnerPlaintext.real_type after decryption.
Paragraph (version A):
IANA is requested to allocate an entry to the existing TLS
"ExtensionType Values" registry, defined in RFC5246, for
connection_id(TBD) defined in this document.
Paragraph (version B):
IANA is requested to allocate an entry to the existing TLS
"ExtensionType Values" registry, defined in RFC5246, for
connection_id(TBD1) defined in this document.
Draft: draft-ietf-tls-dtls-connection-id

Commentary: Addresses 
 Thanks ! This PR clarifies the used cid value . 
 In my opinion , it 's the actual cid on the record header , not the negotiated cid , even if both are intended to be the same . Therefore it is . Or has this changed ? Is the MAC now extended by the negotiated CID ? 
 Fixed with
Paragraph (version A):
Value of the negotiated CID.
Paragraph (version A):
1 byte field indicating the length of the negotiated CID.
Paragraph (version B):
The DTLSCiphertext.cid value.
Paragraph (version B):
1 byte field indicating the length of the DTLSCiphertext.cid.