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

Commentary: be unpredictable in order to prevent pre - computation of CertificateVerify . Maybe this should actually be a MUST ? 
 Note : an attacker can of course forge a complete handshake but maybe for some quirk of the environment that 's not as good .
Paragraph (version A):
An opaque string which identifies the certificate request and
which will be echoed in the client's Certificate message.  The
certificate_request_context MUST be unique within the scope of
this connection (thus preventing replay of client
CertificateVerify messages).  This field SHALL be zero length
unless used for the post-handshake authentication exchanges
described in post-handshake-authentication.
Paragraph (version B):
An opaque string which identifies the certificate request and
which will be echoed in the client's Certificate message.  The
certificate_request_context MUST be unique within the scope of
this connection (thus preventing replay of client
CertificateVerify messages).  This field SHALL be zero length
unless used for the post-handshake authentication exchanges
described in post-handshake-authentication.  When requesting post-
handshake authentication, the server SHOULD make the context
unpredictable to the client (e.g., by randomly generating it) in
order to prevent an attacker who has temporary access to the
client's private key from pre-computing valid CertificateVerify
messages.
Draft: draft-ietf-tls-tls13

Commentary: Explicitly define RFC 7250 certificate support . 
 Seems reasonable . ( I did not try to audit the rest of the text to see if there are other places that need updating . ) 
 This captures what we talked about in Chicago . 
 Shucks , this has n't landed yet , so I 'll have to remember to update my editorial changes pull request that puts the numbers for these into the enumerated type definition for extensions .
Paragraph (version A):
This is a sequence (chain) of CertificateEntry structures, each
containing a single certificate and set of extensions.  The
sender's certificate MUST come in the first CertificateEntry in
the list.  Each following certificate SHOULD directly certify one
preceding it.  Because certificate validation requires that trust
anchors be distributed independently, a certificate that specifies
a trust anchor MAY be omitted from the chain, provided that
supported peers are known to possess any omitted certificates.
Paragraph (version B):
This is a sequence (chain) of CertificateEntry structures, each
containing a single certificate and set of extensions.
Paragraph (version B):
If the corresponding certificate type extension
("server_certificate_type" or "client_certificate_type") was not used
or the X.509 certificate type was negotiated, then each
CertificateEntry contains an X.509 certificate.  The sender's
certificate MUST come in the first CertificateEntry in the list.
Each following certificate SHOULD directly certify one preceding it.
Because certificate validation requires that trust anchors be
distributed independently, a certificate that specifies a trust
anchor MAY be omitted from the chain, provided that supported peers
are known to possess any omitted certificates.
Paragraph (version B):
If the RawPublicKey certificate type was negotiated, then the
certificate_list MUST contain no more than one CertificateEntry,
which contains an ASN1_subjectPublicKeyInfo value as defined in
RFC7250, Section 3.
Draft: draft-ietf-tls-tls13

Commentary: missed a spot . 
 : +1 : Having a definition on when EOED must be sent is good for both interoperability and as a guildeline of how  support should be implemented .
Paragraph (version A):
The EndOfEarlyData message is sent by the client to indicate that all
0-RTT application_data messages have been transmitted (or none will
be sent at all) and that the following records are protected under
handshake traffic keys.  Servers MUST NOT send this message and
clients receiving it MUST terminate the connection with an
"unexpected_message" alert.  This message is encrypted under keys
derived from the client_early_traffic_secret.
Paragraph (version B):
If the server sent an "early_data" extension, the client MUST send an
EndOfEarlyData after receiving the server Finished.  This indicates
that all 0-RTT application_data messages, if any, have been
transmitted and that the following records are protected under
handshake traffic keys.  Servers MUST NOT send this message and
clients receiving it MUST terminate the connection with an
"unexpected_message" alert.  This message is encrypted under keys
derived from the client_early_traffic_secret.
Draft: draft-ietf-tls-tls13

Commentary: the list to the new transcript hash section . that EndOfEarlyData goes in the client   . 
 lgtm
Paragraph (version B):
For concreteness, the transcript hash is always taken from the
following sequence of handshake messages, starting at the first
ClientHello and including only those messages that were sent:
ClientHello, HelloRetryRequest, ClientHello, ServerHello,
EncryptedExtensions, Server CertificateRequest, Server Certificate,
Server CertificateVerify, Server Finished, EndOfEarlyData, Client
Certificate, Client CertificateVerify, Client Finished.
Paragraph (version A):
The complete transcript passed to Derive-Secret is always taken from
the following sequence of handshake messages, starting at the first
ClientHello and including only those messages that were sent:
ClientHello, HelloRetryRequest, ClientHello, ServerHello,
EncryptedExtensions, Server CertificateRequest, Server Certificate,
Server CertificateVerify, Server Finished, EndOfEarlyData, Client
Certificate, Client CertificateVerify, Client Finished.
Draft: draft-ietf-tls-tls13

Commentary: … appens rather than on receipt of handshake messages . It is only actually necessary to verify that a handshake message aligns with a key change when changing keys , not when receiving the message , and it can be simpler to implement the check in this way . This change requires senders to align all these messages with a record boundary as before , but only requires recipients to verify the record boundary when the key change actually happens .
Paragraph (version A):
Handshake messages MUST NOT span key changes.  Because the
ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate
messages can arrive immediately prior to a key change, upon
receiving these messages a receiver MUST verify that the end of
these messages aligns with a record boundary; if not, then it MUST
terminate the connection with an "unexpected_message" alert.
Paragraph (version B):
Handshake messages MUST NOT span key changes.  Implementations
MUST verify that all messages immediately preceding a key change
align with a record boundary; if not, then they MUST terminate the
connection with an "unexpected_message" alert.  Because the
ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate
messages can immediately precede a key change, implementations
MUST send these messages in alignment with a record boundary.
Draft: draft-ietf-tls-tls13

Commentary: I think this addresses the issue raised by   without changing the semantics of the protocol . 
 I will give a post - merge " seems fine " , since I was so vocal in trying to nail down what  wanted . 
 Mentions of non - existent yet RFCs look weird to me but heh
Paragraph (version A):
When authenticating via a certificate (i.e., when a PSK is not in
use), the server will send the Certificate (certificate) and
CertificateVerify (certificate-verify) messages.
Paragraph (version B):
When authenticating via a certificate, the server will send the
Certificate (certificate) and CertificateVerify (certificate-
verify) messages.  In TLS 1.3 as defined by this document, either
a PSK or a certificate is always used, but not both.  Future
documents may define how to use them together.
Draft: draft-ietf-tls-tls13

Commentary: An EndOfEarlyData message signals a key change . A ClientHello can be the last message read before a key is changed , and it never makes sense for a ClientHello to have more data after it in the record .
Paragraph (version A):
Handshake messages MUST NOT span key changes.  Because the
ServerHello, Finished, and KeyUpdate messages signal a key change,
upon receiving these messages a receiver MUST verify that the end
of these messages aligns with a record boundary; if not, then it
MUST terminate the connection with an "unexpected_message" alert.
Paragraph (version B):
Handshake messages MUST NOT span key changes.  Because the
ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate
messages can arrive immediately prior to a key change, upon
receiving these messages a receiver MUST verify that the end of
these messages aligns with a record boundary; if not, then it MUST
terminate the connection with an "unexpected_message" alert.
Draft: draft-ietf-tls-tls13

Commentary: ( Post - merge lgtm since I was summoned . )
Paragraph (version B):
Note that in principle it is possible to continue issuing new tickets
which continue to indefinitely extend the lifetime of the keying
material originally derived from an initial non-PSK handshake (which
was most likely tied to the peer's certificate).  It is RECOMMENDED
that implementations place limits on the total lifetime of such
keying material; these limits should take into account the lifetime
of the peer's certificate, the likelihood of intervening revocation,
and the time since the peer's online CertificateVerify signature.
Draft: draft-ietf-tls-tls13

Commentary: I wonder why this was only a before . Am I right to assume that this is because TLS 1.3 has removed support for static DH and leaking an ephemeral key is not considered to be a security problem ? 
 Got ta say , I do n't know why this was SHOULD . That check is very easy to implement . 
 says . 
 This text was adapted from some old draft of 7919 which had should and never got updated ( see for instance : ) . Good catch . 
 Please provide a PR adding yourself to contributors .
Paragraph (version A):
Peers SHOULD validate each other's public key Y by ensuring that 1 <
Y < p-1.  This check ensures that the remote peer is properly behaved
and isn't forcing the local system into a small subgroup.
Paragraph (version B):
Peers MUST validate each other's public key Y by ensuring that 1 < Y
< p-1.  This check ensures that the remote peer is properly behaved
and isn't forcing the local system into a small subgroup.
Draft: draft-ietf-tls-tls13

Commentary: Found using .
Paragraph (version A):
The byte encoding of a handshake or an alert message, or the the
raw bytes of the application's data to send.
Paragraph (version B):
The byte encoding of a handshake or an alert message, or the raw
bytes of the application's data to send.
Draft: draft-ietf-tls-tls13

Commentary: Was already present for server ; add it for client . Add me to contributors ( if appropriate )
Paragraph (version B):
A server may also request that a client present OCSP response with
its certificate.  In this case, the body of the "status_request"
extension from the client MUST be a CertificateStatus structure as
defined in RFC6066.
Draft: draft-ietf-tls-tls13

Commentary: benefits : ( 1 ) Restoring extract / expand parity , thus cleaning up the theoretical treatment wrt HKDF and future replacements . ( 2 ) Futureproofing against someone being able to force the ECDHE value in the second HKDF - Extract to collide with one of the labels . This seems unlikely with current groups , but might be possible with some future algorithm . ( Issue due to Trevor Perrin ) . 
 This is mostly a cosmetic thing , and I 'm not sure if I actually like all of my proposals below : With the current scheme , the key schedule is very simple and neatly encompassed into a box with a shape like this : NewTLS13KeySchedule(hash ) = creates a new schedule with base secret = 0 AddEntropy(sched , ikm ) = HKDF - Extract ikm into the current base secret DeriveSecret(sched , label ) = take the current base secret and handshake transcript and derive a particular secret with the label This breaks the symmetry in a few ways : a new IKM requires an extra label for the Derive - Secret operation in the middle . from 0 to Early Secret does not involve a Derive - Secret . use Derive - Secret , Derive - Secret no longer always uses the current state of the handshake transcript ( 1 ) could be resolved by just using the same label for both , like " prepare extract " or something . I do n't believe this breaks anything ? We 're just trying to fix the problem where HKDF - Extract and HKDF - Expand ca n't be used on the same key . ( 3 ) is actually kind of odd because Derive - Secret is defined as : Derive - Secret(Secret , Label , Messages ) = HKDF - Expand - Label(Secret ,  , Hash(Messages ) , Hash . Length ) So we 're actually putting Hash ( " " ) into HKDF - Expand - Label , not the empty string . Then again , it feels odd making them ClientHello ... ServerHello and ClientHello ...   , respectively . We could use HKDF - Expand - Label directly which still gives us the separation , but it 's not as obvious . Adding an extra Derive - Secret just to fix ( 2 ) feels a little pointless but would increase symmetry . ( Alternatively , the answer could just be " deal with it , your key schedule box should have slightly richer methods on it " . Like I said , this is just cosmetic . ) 
 I 'm ambivalent on  's gripe . This seems fine to me . One editorial suggestion though . This is now a very tall diagram . You can save a few lines by changing to something like this 
 About this PR , there is a con : complicating the already complicated key schedule 
 It does not seem especially complicated compared to , e.g. , Kerberos . Or maybe that 's just me . 
 well , you 're comparing it to Kerberos : rofl : 
 I fixed . I think we can live without . We already have this " empty hash " construct for the binder keys , so while it 's a bit goofy it 's no more goofy than here . 
 We seem to have reached consensus that the record layer will use the AEAD form only . The stream and CBC forms will be removed . 
 Fixed .
Paragraph (version B):
Add pre-extract Derive-Secret stages to key schedule (*).
Draft: draft-ietf-tls-tls13

Commentary: Add reference to label format in 5705 . address issue 
 refer the reader to exporter requirements in RFC 5705 " Requirements for the format of Exporter labels are defined in section 4 of RFC5705 . " Creating pull request . 
 should we expect a PR ? 
 This appears to be done . 
 yes I submitted PR which has been merged already .
Paragraph (version B):
Requirements for the format of exporter labels are defined in section
4 of RFC5705.
Draft: draft-ietf-tls-tls13

Commentary: Per the recent thread . I could have sworn this was in here , but ca n't find it ... The NewSessionTicket section explicitly says to ignore unknown extensions , so I 've the analogous text to ClientHello and CertificateRequest .
Paragraph (version A):
Clients request extended functionality from servers by sending
data in the extensions field.  The actual "Extension" format is
defined in extensions.  In TLS 1.3, use of certain extensions is
mandatory, as functionality is moved into extensions to preserve
ClientHello compatibility with previous versions of TLS.
Paragraph (version B):
Clients request extended functionality from servers by sending
data in the extensions field.  The actual "Extension" format is
defined in extensions.  In TLS 1.3, use of certain extensions is
mandatory, as functionality is moved into extensions to preserve
ClientHello compatibility with previous versions of TLS.  Servers
MUST ignore unrecognized extensions.
Paragraph (version A):
An optional set of extensions describing the parameters of the
certificate being requested.  The "signature_algorithms" extension
MUST be specified.
Paragraph (version B):
An optional set of extensions describing the parameters of the
certificate being requested.  The "signature_algorithms" extension
MUST be specified.  Clients MUST ignore unrecognized extensions.
Draft: draft-ietf-tls-tls13

Commentary: confirmed in the face - to - face conversation .
Paragraph (version A):
For each ticket, the time since the client learned about the
server configuration that it is using, in milliseconds.  This
value is added modulo 2^32 to with the "ticket_age_add" value that
was included with the ticket, see NewSessionTicket.  This addition
prevents passive observers from correlating sessions unless
tickets are reused.  Note: because ticket lifetimes are restricted
to a week, 32 bits is enough to represent any plausible age, even
in milliseconds.  For identities established externally an
obfuscated_ticket_age of 0 SHOULD be used, and servers MUST ignore
the value.
Paragraph (version B):
For each ticket, the time since the client learned about the
server configuration that it is using, in milliseconds.  This
value is added modulo 2^32 to the "ticket_age_add" value that was
included with the ticket, see NewSessionTicket.  This addition
prevents passive observers from correlating sessions unless
tickets are reused.  Note: because ticket lifetimes are restricted
to a week, 32 bits is enough to represent any plausible age, even
in milliseconds.  For identities established externally an
obfuscated_ticket_age of 0 SHOULD be used, and servers MUST ignore
the value.
Draft: draft-ietf-tls-tls13

Commentary:  is now . sandj - tls - iana - registry - updates is now ietf - tls - iana - registry - updates .
Paragraph (version A):
Indicates a signature algorithm using EdDSA as defined in I-
D.irtf-cfrg-eddsa or its successors.  Note that these correspond
to the "PureEdDSA" algorithms and not the "prehash" variants.
Paragraph (version B):
Indicates a signature algorithm using EdDSA as defined in RFC8032
or its successors.  Note that these correspond to the "PureEdDSA"
algorithms and not the "prehash" variants.
Draft: draft-ietf-tls-tls13

Commentary: ( This does n't break ticketageadd because it 's additive . )
Paragraph (version A):
Updating the PSK binder values if the "pre_shared_key" extension
was present.
Paragraph (version B):
Updating the "obfuscated_ticket_age" and PSK binder values if the
"pre_shared_key" extension was present.
Draft: draft-ietf-tls-tls13

Commentary: This is a giant pile of nitpicks , loosely inspired by the FFDHE alert discussion . The old text specifies a handshakefailure which is redundant with and contradicts the Cryptographic Negotiation section . The old text says only handshakefailure is allowed while Cryptographic Negotiation allows both handshakefailure and insufficientsecurity . Fix this by avoiding redundancy as the failure cases are global to the overall negotiation algorithm . Next , align the tense with itself and the rest of the text . Most of the text appears to be written in present tense . The old text for SH said : The server will send [ ... ] when it was able to [ ... ] which is a little odd . Also align the wording between the two . Talk about a server ( singular ) to match Cryptographic Negotiation and say " parameters " rather than " algorithms " or " algorithms and groups " . Also be consistent about the SH vs.  condition . The SH section said " the client ’s key_share extension was acceptable " while the HRR section said " the client ’s ClientHello did not contain sufficient information to proceed with the handshake " . Use the more general one . 
 Seems reasonable . I a little bit wondered whether to replace " it " with " the server " , but the pronoun 's meaning should be clear , here . 
 Seems clear enough to me , but I 'm equally happy with the other wording . shrug 
 This does seem clearer . And shorter !
Paragraph (version A):
The server will send this message in response to a ClientHello
message when it was able to find an acceptable set of algorithms and
the client's "key_share" extension was acceptable.  If it is not able
to find an acceptable set of parameters, the server will respond with
a "handshake_failure" fatal alert.
Paragraph (version B):
The server will send this message in response to a ClientHello
message if it is able to find an acceptable set of parameters and the
ClientHello contains sufficient information to proceed with the
handshake.
Paragraph (version A):
Servers send this message in response to a ClientHello message if
they were able to find an acceptable set of algorithms and groups
that are mutually supported, but the client's ClientHello did not
contain sufficient information to proceed with the handshake.  If a
server cannot successfully select algorithms and groups, it MUST
abort the handshake with a "handshake_failure" alert.
Paragraph (version B):
The server will send this message in response to a ClientHello
message if it is able to find an acceptable set of parameters but the
ClientHello does not contain sufficient information to proceed with
the handshake.
Draft: draft-ietf-tls-tls13

Commentary: minor additions , the context string was n't explained anywhere as well so I thought a mini - line would help .
Paragraph (version A):
This structure is intended to prevent an attack on previous versions
of TLS in which the ServerKeyExchange format meant that attackers
could obtain a signature of a message with a chosen, 32-byte prefix.
The initial 64 byte pad clears that prefix.
Paragraph (version A):
The context string for a server signature is "TLS 1.3, server
CertificateVerify" and for a client signature is "TLS 1.3, client
CertificateVerify".
Paragraph (version B):
This structure is intended to prevent an attack on previous versions
of TLS in which the ServerKeyExchange format meant that attackers
could obtain a signature of a message with a chosen 32-byte prefix
(ClientHello.random).  The initial 64 byte pad clears that prefix.
Paragraph (version B):
The context string for a server signature is "TLS 1.3, server
CertificateVerify" and for a client signature is "TLS 1.3, client
CertificateVerify".  It is used to provide separation between
signatures made in different contexts, helping against potential
cross-protocol attacks.