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

Commentary: In response to feedback on the mailing list ( ) , this PR attempts to clarify ( a ) when to generate ACKs , and ( b ) which records to ACK . 
 This is much clearer to me . I see that you have removed the sentence I was having a problem with in the bullet : " Implementations MUST NOT send ACKs for handshake messages which they discard as out - of - order , because otherwise those messages will not be retransmitted " ; logically , I believe you have captured this better by adding " and processed " above in " The ACK message is used by an endpoint to indicate which handshake records it has received and processed from the other side . " 
 Thank you for your feedback ! I have removed the sentence because its content is already implied by what 's stated in the previous section . See the commit description of 
 thanks . This sensibly improves readability and clarity .
Mailing list commentary: Hi Hanno , Thank you for your clarifications . The example you gave helps a lot . I believe I now understand the text as written in this bullet ( first bullet , not second -- my bad ) . I no longer think it needs re - wording . Best regards ,
Paragraph (version A):
The ACK message is used by an endpoint to indicate handshake-
containing the TLS records it has received from the other side.  ACK
is not a handshake message but is rather a separate content type,
with code point TBD (proposed, 25).  This avoids having ACK being
added to the handshake transcript.  Note that ACKs can still be sent
in the same UDP datagram as handshake records.
Paragraph (version B):
The ACK message is used by an endpoint to indicate which handshake
records it has received and processed from the other side.  ACK is
not a handshake message but is rather a separate content type, with
code point TBD (proposed, 25).  This avoids having ACK being added to
the handshake transcript.  Note that ACKs can still be sent in the
same UDP datagram as handshake records.
Paragraph (version A):
Implementations MUST NOT acknowledge records containing non-
duplicative handshake messages or fragments which have not been
processed or buffered.  Otherwise, deadlock can ensue.
Paragraph (version B):
Implementations MUST NOT acknowledge records containing handshake
messages or fragments which have not been processed or buffered.
Otherwise, deadlock can ensue.  As an example, implementations MUST
NOT send ACKs for handshake messages which they discard as out-of-
order.
Paragraph (version A):
When they receive a message or fragment which is out of order,
either because it is not the next expected message or because it
is not the next piece of the current message.  Implementations
MUST NOT send ACKs for handshake messages which they discard as
out-of-order, because otherwise those messages will not be
retransmitted.
Paragraph (version B):
When they receive a message or fragment which is out of order,
either because it is not the next expected message or because it
is not the next piece of the current message.
Draft: draft-ietf-tls-dtls13

Commentary:   writes : I have a minor comment on DTLS 1.3 draft 37 . On the topic of sending ACKs , the draft recommends : I wonder if the case of post - handshake authentication should be explicitly mentioned as a potential exception to this rule , since the TLS 1.3 RFC explicitly mentions that responses to may be delayed in some contexts : In this case , it would be beneficial to immediately explicitly ACK the message even though it is also implicitly acked through the eventual response via the message .
Paragraph (version A):
In addition, implementations MUST send ACKs upon receiving all of any
flight which they do not respond to with their own messages.
Specifically, this means the client's final flight of the main
handshake, the server's transmission of the NewSessionTicket, and
KeyUpdate messages.  ACKs SHOULD NOT be sent for other complete
flights because they are implicitly acknowledged by the receipt of
the next flight, which generally immediately follows the flight.
Each NewSessionTicket or KeyUpdate is an individual flight; in
particular, a KeyUpdate sent in response to a KeyUpdate with
update_requested does not implicitly acknowledge that message.
Implementations MAY acknowledge the records corresponding to each
transmission of that flight or simply acknowledge the most recent
one.
Paragraph (version B):
In addition, implementations MUST send ACKs upon receiving all of any
flight which they do not respond to with their own messages.
Specifically, this means the client's final flight of the main
handshake, the server's transmission of the NewSessionTicket, and
KeyUpdate messages.  ACKs SHOULD NOT be sent for other complete
flights because they are implicitly acknowledged by the receipt of
the next flight, which generally immediately follows the flight,
unless generating the responding flight takes significant time.  In
this case, implementations MAY send explicit ACKs for the complete
received flight even though it will eventually also be implicitly
acknowledged through the responding flight.  A notable example for
this is the case of post-handshake client authentication in
constrained environments, where generating the CertificateVerify
message can take considerable time on the client.
Paragraph (version B):
Each NewSessionTicket or KeyUpdate is an individual flight; in
particular, a KeyUpdate sent in response to a KeyUpdate with
update_requested does not implicitly acknowledge that message.
Implementations MAY acknowledge the records corresponding to each
transmission of that flight or simply acknowledge the most recent
one.
Draft: draft-ietf-tls-dtls13

Commentary: The previous version erroneously specified that implementations should transition from SENDING to FINISHED after sending the last flight in a handshake . Instead , they should transition to WAITING and only move to FINISHED upon receipt of ACKs for the entire last flight . This PR fixes the state machine diagram and text . 
 lgtm
Paragraph (version A):
In the SENDING state, the implementation transmits the buffered
flight of messages.  If the implementation has received one or more
ACKs (see ack-msg) from the peer, then it SHOULD omit any messages or
message fragments which have already been ACKed.  Once the messages
have been sent, the implementation then enters the FINISHED state if
this is the last flight in the handshake.  Or, if the implementation
expects to receive more messages, it sets a retransmit timer and then
enters the WAITING state.
Paragraph (version B):
In the SENDING state, the implementation transmits the buffered
flight of messages.  If the implementation has received one or more
ACKs (see ack-msg) from the peer, then it SHOULD omit any messages or
message fragments which have already been ACKed.  Once the messages
have been sent, the implementation then sets a retransmit timer and
enters the WAITING state.
Draft: draft-ietf-tls-dtls13

Commentary: Based on feedback from Hanno and  on the list . 
 Thanks looks good to me .
Paragraph (version A):
Although KeyUpdate MUST be acknowledged, it is possible for the ACK
to be lost, in which case the sender of the KeyUpdate will retransmit
it.  Implementations MUST retain the ability to ACK the KeyUpdate for
up to 2MSL.  It is RECOMMENDED that they do so by retaining the pre-
update keying material, but they MAY do so by responding to messages
which appear to be out-of-epoch with a canned ACK message; in this
case, implementations SHOULD rate limit how often they send such
ACKs.
Paragraph (version B):
Due to the possibility of an ACK message for a KeyUpdate being lost
and thereby preventing the sender of the KeyUpdate from updating its
keying material, receivers MUST retain the pre-update keying material
until receipt and successful decryption of a message using the new
keys.
Draft: draft-ietf-tls-dtls13

Commentary: … ssed 
 LGTM modulo two nits .
Paragraph (version A):
a list of the records containing handshake messages in the current
flight which the endpoint has received, in numerically increasing
order.  ACKs only cover the current outstanding flight (this is
possible because DTLS is generally a lockstep protocol).  Thus, an
ACK from the server would not cover both the ClientHello and the
client's Certificate.  Implementations can accomplish this by
clearing their ACK list upon receiving the start of the next
flight.
Paragraph (version B):
a list of the records containing handshake messages in the current
flight which the endpoint has received and either processed or
buffered, in numerically increasing order.
Paragraph (version B):
Implementations MUST NOT acknowledge records containing non-
duplicative handshake messages or fragments which have not been
processed or buffered.  Otherwise, deadlock can ensue.
Paragraph (version B):
During the handshake, ACKs only cover the current outstanding flight
(this is possible because DTLS is generally a lockstep protocol).
Thus, an ACK from the server would not cover both the ClientHello and
the client's Certificate.  Implementations can accomplish this by
clearing their ACK list upon receiving the start of the next flight.
Paragraph (version B):
After the handshake, ACKs SHOULD be sent once for each received and
processed record (potentially subject to some delay) and MAY cover
more than one flight.
Draft: draft-ietf-tls-dtls13

Commentary: I ca n't reconcile : ... with : The MUSTs in these appear to be pulling in opposite directions . I suspect that the latter is correct though . It is possible that a DTLS 1.3 client could get a legacy cookie from a DTLS 1.2 server , so that it is valid for the legacy cookie to appear when supported_versions includes DTLS 1.3 . However , that represents an attack and a DTLS 1.3 server should n't continue to establish the connection . Maybe it is n't a bad attack because the client does n't change its posture in ways that would materially affect the resulting session , but we have generally tried to avoid these .
Paragraph (version A):
The cookie extension is defined in Section 4.2.2 of TLS13.  When
sending the initial ClientHello, the client does not have a cookie
yet.  In this case, the cookie extension is omitted and the
legacy_cookie field in the ClientHello message SHOULD be set to a
zero length vector (i.e., a single zero byte length field) and MUST
be ignored by a server negotiating DTLS 1.3.
Paragraph (version B):
The cookie extension is defined in Section 4.2.2 of TLS13.  When
sending the initial ClientHello, the client does not have a cookie
yet.  In this case, the cookie extension is omitted and the
legacy_cookie field in the ClientHello message MUST be set to a zero
length vector (i.e., a single zero byte length field).
Draft: draft-ietf-tls-dtls13

Commentary: I - D.ietf - tls - dtls - connection - id became a normative reference Removed duplicate reference to I - D.ietf - tls - dtls - connection - id .
Paragraph (version A):
Variable length CID.  The CID concept is described in DTLS-CID.
An example can be found in connection-id-example.
Paragraph (version B):
Variable length CID.  The CID concept is described in I-D.ietf-
tls-dtls-connection-id.  An example can be found in connection-id-
example.
Paragraph (version A):
DTLS records, as defined in this document, do not contain any
association identifiers and applications must arrange to multiplex
between associations.  With UDP, the host/port number is used to look
up the appropriate security association for incoming records.
However, the CID extension defined in DTLS-CID adds an association
identifier to DTLS records.
Paragraph (version B):
DTLS records, as defined in this document, do not contain any
association identifiers and applications must arrange to multiplex
between associations.  With UDP, the host/port number is used to look
up the appropriate security association for incoming records.
However, the CID extension defined in I-D.ietf-tls-dtls-connection-id
adds an association identifier to DTLS records.
Paragraph (version A):
If the client and server have negotiated the "connection_id"
extension DTLS-CID, either side can send a new CID which it wishes
the other side to use in a NewConnectionId message.
Paragraph (version B):
If the client and server have negotiated the "connection_id"
extension I-D.ietf-tls-dtls-connection-id, either side can send a new
CID which it wishes the other side to use in a NewConnectionId
message.
Paragraph (version A):
Note: The connection_id extension is defined in DTLS-CID, which is
used in ClientHello and ServerHello messages.
Paragraph (version B):
Note: The connection_id extension is defined in I-D.ietf-tls-dtls-
connection-id, which is used in ClientHello and ServerHello messages.
Draft: draft-ietf-tls-dtls13

Commentary: omit the trailing space because TLS 1.3 went right up to the limit . 
 No , no , DTLS also uses HKDR for Key Separation++ 
 Hearing no objections , we 're merging this change . I 'll fix the HKDR - HKDF typo in a followup PR . 
 This is perfectly fine . Thanks for making the edit .
Paragraph (version B):
Section 7.1 of RFC8446 specifies that HKDR-Expand-Label uses a label
prefix of "tls13 ".  For DTLS 1.3, that label SHALL be "dtls13".
This ensures key separation between DTLS 1.3 and TLS 1.3.  Note that
there is no trailing space; this is necessary in order to keep the
overall label size inside of one hash iteration because "DTLS" is one
letter longer than "TLS".
Draft: draft-ietf-tls-dtls13

Commentary: Deleted the following statement : " Until the handshake has completed , implementations MUST accept packets from the old epoch . " because it appears to be redundant . Martin raised this issue in 
 I think that this is a vestige of renegotiation and can be removed . But we might want to say something more helpful about accepting 0 - RTT and Handshake at the same time . 
 I think we should delete this sentence because it is redundant . We have already text in the same section saying the following : " Because DTLS records could be reordered , a record from epoch 1 may be received after epoch 2 has begun . In general , implementations SHOULD discard packets from earlier epochs , but if packet loss causes noticeable problems implementations MAY choose to retain keying material from previous epochs for up to the default MSL specified for TCP to allow for packet reordering . " If you think there is someone else that should be said , we are happy to add it . Here is the PR : 
 Fixed .
Paragraph (version A):
Because DTLS records could be reordered, a record from epoch 1 may be
received after epoch 2 has begun.  In general, implementations SHOULD
discard packets from earlier epochs, but if packet loss causes
noticeable problems implementations MAY choose to retain keying
material from previous epochs for up to the default MSL specified for
TCP RFC0793 to allow for packet reordering.  (Note that the intention
here is that implementers use the current guidance from the IETF for
MSL, as specified in RFC0793 or successors not that they attempt to
interrogate the MSL that the system TCP stack is using.)  Until the
handshake has completed, implementations MUST accept packets from the
old epoch.
Draft: draft-ietf-tls-dtls13

Commentary: Addressing issue raised by  at 
 Should the server reject the ClientHello if it appears as though the client is responding to a HelloVerifyRequest ? What if it also contains a cookie extension ? 
 I do n't think the server should reject a ClientHello if it thinks the  should provide a cookie previously sent with the HelloVerifyRequest . This would require the server to keep state and to implement more complex logic in the server - side . If the ClientHello contains a cookie in the ClientHello.legacycookie field in the DTLS 1.3 field then IMHO an " illegalparameter " alert has to be sent . I created a PR to add a note about this : There is , however , the question why whether we should omit some of the legacy fields for use with DTLS 1.3 ( not in the ClientHello because it would be needed for backwards compatibility ) but for the ServerHello / HelloRetryRequest . 
 Fixed
Paragraph (version A):
A DTLS 1.3-only client MUST set the legacy_cookie field to zero
length.
Paragraph (version B):
A DTLS 1.3-only client MUST set the legacy_cookie field to zero
length.  If a DTLS 1.3 ClientHello is received with any other
value in this field, the server MUST abort the handshake with an
"illegal_parameter" alert.
Draft: draft-ietf-tls-dtls13

Commentary: I this remark following my implementation experience of DTLS 1.2 CID followed by the work on the DTLS 1.3 . We noticed this issue at the Prague IETF meeting ( March 2019 ) .
Paragraph (version A):
The entire header value shown above is used as it appears on the wire
as the additional data value for the AEAD function.
Paragraph (version B):
The entire header value shown above is used as it appears on the wire
as the additional data value for the AEAD function.  Note that this
design is different to the additional data calculation for DTLS 1.2
and for DTLS 1.2 with Connection ID.
Draft: draft-ietf-tls-dtls13

Commentary: The draft states in three places that DTLS use explicit sequence numbers , while this was true for DTLS 1.2 , the sequence number in the DTLSCipherstructure is a mixture of implicit and explict . Maybe " Partly Explicit " ? 
 Please provide me with a PR to add your name to acknowledgements . 
 Hi , I do n’t know what PR is an abbreviation for but I guess it is not clear from my username who I am . I should probably update it , I did not intend to be anonymous :)   , Ericsson ,
Paragraph (version A):
TLS does not allow independent decryption of individual records.
Because the integrity check indirectly depends on a sequence
number, if record N is not received, then the integrity check on
record N+1 will be based on the wrong sequence number and thus
will fail.  DTLS solves this problem by adding explicit sequence
numbers.
Paragraph (version B):
TLS does not allow independent decryption of individual records.
Because the integrity check indirectly depends on a sequence
number, if record N is not received, then the integrity check on
record N+1 will be based on the wrong sequence number and thus
will fail.  DTLS solves this problem by adding sequence numbers.
Paragraph (version A):
DTLS adds an explicit epoch and sequence number to the TLS record
header.  This sequence number allows the recipient to correctly
verify the DTLS MAC.  However, the number of bits used for the
epoch and sequence number fields in the DTLSCiphertext structure
have been reduced.
Paragraph (version B):
DTLS adds an epoch and sequence number to the TLS record header.
This sequence number allows the recipient to correctly verify the
DTLS MAC.  However, the number of bits used for the epoch and
sequence number fields in the DTLSCiphertext structure have been
reduced.
Paragraph (version A):
DTLS uses an explicit sequence number, rather than an implicit one,
carried in the sequence_number field of the record.  Sequence numbers
are maintained separately for each epoch, with each sequence_number
initially being 0 for each epoch.
Paragraph (version B):
DTLS uses an explicit or partly explicit sequence number, rather than
an implicit one, carried in the sequence_number field of the record.
Sequence numbers are maintained separately for each epoch, with each
sequence_number initially being 0 for each epoch.
Draft: draft-ietf-tls-dtls13

Commentary: Suggested pull request related to issue 
 The Abstract states that : " The DTLS 1.3 protocol is intentionally based on the Transport Layer Security ( TLS ) 1.3 protocol and provides equivalent security guarantees . " This is not true when it comes to Order protection / non - replayability which is states as a guarantee in   of RFC 8446 . DTLS does not provide order protection and may not provide replay protection . I suggested this statement " equivalent security guarantees " is deleted ( or rewritten ) in the abstract and that some short text describing this is to the Security Considerations . 
 Fixed .
Paragraph (version A):
The DTLS 1.3 protocol is intentionally based on the Transport Layer
Security (TLS) 1.3 protocol and provides equivalent security
guarantees.  Datagram semantics of the underlying transport are
preserved by the DTLS protocol.
Paragraph (version B):
The DTLS 1.3 protocol is intentionally based on the Transport Layer
Security (TLS) 1.3 protocol and provides equivalent security
guarantees with the exception of order protection/non-replayability.
Datagram semantics of the underlying transport are preserved by the
DTLS protocol.
Paragraph (version B):
With the exception of order protection and non-replayability, the
security guarantees for DTLS 1.3 are the same as TLS 1.3.  While TLS
always provides order protection and non-replayability, DTLS does not
provide order protection and may not provide replay protection.
Draft: draft-ietf-tls-dtls13

Commentary: s'OK wi ' me . The other thing to consider mentioning is that record shadowing ( key compromise at epoch N allowing the attacker to send records that cause records at epoch N to be dropped ) is n't a concern because dropping records in DTLS is trivial . 
 thoughts ?
Paragraph (version B):
The DTLS 1.3 handshake has one important difference from the TLS 1.3
handshake: the EndOfEarlyData message is omitted both from the wire
and the handshake transcript: because DTLS records have epochs,
EndOfEarlyData is not necessary to determine when the early data is
complete, and because DTLS is lossy, attackers can trivially mount
the deletion attacks that EndOfEarlyData prevents in TLS.  Servers
SHOULD aggressively age out the epoch 1 keys upon receiving the first
epoch 1 record and SHOULD NOT accept epoch 1 data after the first
epoch 3 record is received.
Draft: draft-ietf-tls-dtls13

Commentary: As I understand , the intent with the record header in AD business was so that DTLS 1.3 would inherit putting the entire header into the AD . However , TLS 1.3 defines the AD as : and DTLS 1.3 defines encryptedrecord as : If one takes the first half of the clause , it works out , but " record header " is n't defined formally . If one takes the second half , it suggests that is not in the AD and it 's not clear how 's AD is defined at all . Probably worth clarifying this .
Paragraph (version B):
The entire header value shown above is used as it appears on the wire
as the additional data value for the AEAD function.
Draft: draft-ietf-tls-dtls13

Commentary: I split and reordered the paragragh to maintain the integrity of the " aside from these exceptions , this is TLS 1.3 " .
Paragraph (version A):
With these exceptions, the DTLS message formats, flows, and logic are
the same as those of TLS 1.3.  DTLS implementations SHOULD not use
the TLS 1.3 "compatibility mode" described in I-D.ietf-tls-tls13,
Section D.4 and DTLS servers SHOULD ignore the "session_id" value
generated by the client rather than sending ChangeCipherSpec
messages.  Implementations MUST still ignore ChangeCipherSpec
messages received during the handshake and at all other times SHOULD
treat them as if they had failed to deprotect.
Paragraph (version B):
DTLS implementations do not use the TLS 1.3 "compatibility mode"
described in I-D.ietf-tls-tls13, Section D.4.  DTLS servers MUST NOT
echo the "session_id" value from the client and endpoints MUST NOT
send ChangeCipherSpec messages.  Note however that implementations
MUST ignore ChangeCipherSpec messages received in unprotected
records.
Paragraph (version B):
With these exceptions, the DTLS message formats, flows, and logic are
the same as those of TLS 1.3.