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

Commentary: To let 's add some explanations to Section 3 . 
 I have written a syntax validator to check the validity of definitions . In this issue , I would like to point out what I noticed . 
 ( 1 ) Some enum definitions use " floor .. ceiling " notation which is not defined . Section 3.5 should clearly define this . 
 ( 2 ) I think that the keyword is allowed only in the top level definitions . But is used inside of EarlyDataIndication . I would suggest to defined the following in the top level : 
 ( 3 ) The following assignment is really strange : I would suggest to change this to : 
 On Wednesday , September 07 , 2016 04:24:15 am   wrote : I do n't understand why you consider this current notation here strange . It 's the same notation used for enum values elsewhere . 
 What I can tell from Section 3 is as follows : The " symbol(num ) " notation is allowed in the declaration of enum . " symbol " can be used as label of the case clause . " { num , ... } " can be used for assignment . I do n't see that " symbol(num ) " can be used for assignment . I wrote a parse based on Section 3 and what I reported here is the errors reported by the parser .
Paragraph (version B):
Basically the "struct" notation is used in the top level to define a
new type.  However, there is one exception that an anonymous
structure "struct {}", which means empty, can be used inside of
another structure.
Draft: draft-ietf-tls-tls13

Commentary: This will make life a lot easier
Paragraph (version B):
Merge TicketExtensions and Extensions registry.  Changes
ticket_early_data_info code point (*).
Paragraph (version A):
IANA [shall update/has updated] this registry to include a "TLS
that the server shall not send them.  "Clear", indicating that
they shall be in the ServerHello.  "Encrypted", indicating that
they shall be in the EncryptedExtensions block, "Certificate"
indicating that they shall be in the Certificate block, and "No"
indicating that they are not used in TLS 1.3.  This column [shall
be/has been] initially populated with the values in this document.
Paragraph (version B):
IANA [shall update/has updated] this registry to include a "TLS
that the server shall not send them.  "Clear", indicating that
they shall be in the ServerHello.  "Encrypted", indicating that
they shall be in the EncryptedExtensions block, "Certificate"
indicating that they shall be in the Certificate block, "Ticket"
indicating that they can appear in the NewSessionTicket message
(only) and "No" indicating that they are not used in TLS 1.3.
This column [shall be/has been] initially populated with the
values in this document.
Draft: draft-ietf-tls-tls13

Commentary: On Tuesday , October 11 , 2016 08:14:32 pm   wrote : or missingextension 
 I think that missingextension would be OK , but we would hit the lower - level decodeerror first , since  is defined with :
Paragraph (version A):
Upon receipt of a HelloRetryRequest, the client MUST verify that the
extensions block is not empty and otherwise MUST abort the handshake
with a "decode_error" alert.  Clients SHOULD abort the handshake with
an "unexpected message" if the HelloRetryRequest would not result in
any change in the ClientHello or in response to any second
HelloRetryRequest which was sent in the same connection (i.e., where
the ClientHello was itself in response to a HelloRetryRequest).
Paragraph (version B):
Upon receipt of a HelloRetryRequest, the client MUST verify that the
extensions block is not empty and otherwise MUST abort the handshake
with a "decode_error" alert.  Clients MUST abort the handshake with
an "illegal_parameter" alert if the HelloRetryRequest would not
result in any change in the ClientHello.  If a client receives a
second HelloRetryRequest in the same connection (i.e., where the
ClientHello was itself in response to a HelloRetryRequest), it MUST
abort the handshake with an "unexpected_message" alert.
Draft: draft-ietf-tls-tls13

Commentary: The MTI Extensions section is currently out - of - date . It was n't updated with the new negotiation and still refers to the old cipher suites system . This PR cleans that up . I also drop the cookie extension universal send requirement , as that was in there as an alternative to allowing a server to send a cookie without first being prompted . We have that in as an explicit exception , currently . 
 I already did some of this in PR , so I 'm going to hold this PR until that has landed and then we can take stock 
 Sure , I had n't read that PR yet . A notable difference in the language here is that I 'm replacing the " MAY abort the connection " line with specific requirements , as that high level of generalization is counterproductive now that cipher suites and feature extensions are decoupled .
Paragraph (version A):
"signature_algorithms" is REQUIRED for certificate authenticated
cipher suites.
Paragraph (version A):
"supported_groups" and "key_share" are REQUIRED for DHE or ECDHE
cipher suites.
Paragraph (version A):
"pre_shared_key" is REQUIRED for PSK cipher suites.
Paragraph (version A):
"cookie" is REQUIRED for all cipher suites.
Paragraph (version A):
When negotiating use of applicable cipher suites, endpoints MUST
abort the handshake with a "missing_extension" alert if the required
extension was not provided.  Any endpoint that receives an invalid
combination of cipher suites and extensions MAY abort the connection
with a "missing_extension" alert, regardless of negotiated
parameters.
Paragraph (version B):
"signature_algorithms" is REQUIRED for certificate authentication.
Paragraph (version B):
"supported_groups" and "key_share" are REQUIRED for DHE or ECDHE
key exchange.
Paragraph (version B):
"pre_shared_key" is REQUIRED for PSK key agreement.
Paragraph (version B):
If not containing a "pre_shared_key" extension, it MUST contain
both a "signature_algorithms" extension and a "supported_groups"
extension.
Paragraph (version B):
Servers receiving a ClientHello which is attempting to negotiate
using this specification, yet failing any of the above requirements,
MUST abort the handshake with a "missing_extension" alert.
Draft: draft-ietf-tls-tls13

Commentary: Various changes to make exporters / resumption work better . The rationale is to be able to do stuff in 0/0.5RTT . Add a 0 - RTT exporter and change the transcript for the regular exporter ( * ) . Explicitly allow predicting ClientFinished for NST when not doing  auth .
Paragraph (version A):
Where Secret is either the early_exporter_secret or the
exporter_secret.
Paragraph (version B):
Where Secret is either the early_exporter_secret or the
exporter_secret.  Implementations MUST use the exporter_secret unless
explicitly specified by the application.  When adding TLS 1.3 to TLS
interface.
Draft: draft-ietf-tls-tls13

Commentary: I wanted to clarify in what part of the exchange the certificaterequestcontext field has a zero length .
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).  Within the handshake, this field
MUST be empty.
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 Section 4.5.2.
Draft: draft-ietf-tls-tls13

Commentary: I am proposing that a client can also use the Zero - RTT with PSK - based authentication without having to rely on a previously obtained ticket . 
 Surely there would need to be additional security considerations for this behavior ? ! 
 This seems reasonable and was my intent , at least . Can you fix the build problem . 
 Could you please add linebreaks to wrap to about 80 character or so lines ? Our line length is often rather inconsistent , but we do generally try to keep lines shorter than in the current changeset . 
 This LGTM . I 'll let it sit for a little but in case anyone wants to weigh in ( 
 That 's the sort of additional considerations that I was expecting to see , yes . I think that you got the list basically right , though there are a few things here that could be clearer .
Paragraph (version A):
When resuming via a PSK with an appropriate ticket (i.e., one with
the "early_data_info" extension), clients can also send data on their
first flight ("early data").  This data is encrypted solely under
keys derived using the first offered PSK as the static secret.  As
shown in tls-0-rtt, the Zero-RTT data is just added to the 1-RTT
handshake in the first flight.  The rest of the handshake uses the
same messages as with a 1-RTT handshake with PSK resumption.
Paragraph (version B):
With the Zero-RTT mode clients can send data on their first flight
("early data") whereby the client uses a PSK either obtained out-of-
band or as a ticket (i.e., one with the "early_data_info" extension)
from an earlier exchange to authenticate to the server.
Paragraph (version B):
When clients use a PSK obtained out-of-band then the following
information MUST be provisioned to both parties: * PSK identity, *
ciphersuite for use with this PSK, * key exchange and authentication
modes this PSK is allowed to be used with,
* the Application-Layer Protocol Negotiation (ALPN) label(s), and *
optionally the Server Name Indication (SNI).
Paragraph (version B):
As shown in tls-0-rtt, the Zero-RTT data is just added to the 1-RTT
handshake in the first flight.  The rest of the handshake uses the
same messages as with a 1-RTT handshake with PSK resumption.
Paragraph (version A):
This data is not forward secret, because it is encrypted solely
with the PSK.
Paragraph (version B):
The early data is encrypted solely under keys derived using the
offered PSK as the static secret.  Hence, this data is not forward
secret, because it is encrypted solely with the PSK.
Draft: draft-ietf-tls-tls13

Commentary: Criteria for one member structure / non structure is as follows : Non structure : basic type -- not messages nor extensions One member structure : others such as messages or extensions 
 LGTM
Paragraph (version A):
rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD NOT be offered.
Clients offering these values for backwards compatibility MUST list
them as the lowest priority (listed after all other algorithms in the
supported_signature_algorithms vector).  TLS 1.3 servers MUST NOT
offer a SHA-1 signed certificate unless no valid certificate chain
can be produced without it (see server-certificate-selection).
Paragraph (version B):
rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD NOT be offered.
Clients offering these values for backwards compatibility MUST list
them as the lowest priority (listed after all other algorithms in
SignatureSchemeList).  TLS 1.3 servers MUST NOT offer a SHA-1 signed
certificate unless no valid certificate chain can be produced without
it (see server-certificate-selection).
Draft: draft-ietf-tls-tls13

Commentary: Folks have already gotten this wrong , so add a note here .
Paragraph (version B):
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH Implementations of
draft versions (see draft-version-indicator) of this specification
SHOULD NOT implement this mechanism on either client and server.  A
pre-RFC client connecting to RFC servers, or vice versa, will appear
to downgrade to TLS 1.2.  With the mechanism enabled, this will cause
an interoperability failure.
Draft: draft-ietf-tls-tls13

Commentary: MUST by generated independently -MUST be generated independently
Paragraph (version A):
Clients offer an arbitrary number of KeyShareEntry values, each
representing a single set of key exchange parameters.  For instance,
a client might offer shares for several elliptic curves or multiple
FFDHE groups.  The key_exchange values for each KeyShareEntry MUST by
generated independently.  Clients MUST NOT offer multiple
KeyShareEntry values for the same group.  Clients MUST NOT offer any
KeyShareEntry values for groups not listed in the client's
"supported_groups" extension.  Servers MAY check for violations of
these rules and and MAY abort the handshake with an
"illegal_parameter" alert if one is violated.
Paragraph (version B):
Clients offer an arbitrary number of KeyShareEntry values, each
representing a single set of key exchange parameters.  For instance,
a client might offer shares for several elliptic curves or multiple
FFDHE groups.  The key_exchange values for each KeyShareEntry MUST be
generated independently.  Clients MUST NOT offer multiple
KeyShareEntry values for the same group.  Clients MUST NOT offer any
KeyShareEntry values for groups not listed in the client's
"supported_groups" extension.  Servers MAY check for violations of
these rules and and MAY abort the handshake with an
"illegal_parameter" alert if one is violated.
Draft: draft-ietf-tls-tls13

Commentary: ClientHello.version -ClientHello.legacy_version 
 Merged . Please send me a PR adding yourself to Contributors in alphabetical order 
 Thank you ! Done in PR .
Paragraph (version A):
Servers which are compliant with this specification MUST use only the
"supported_versions" extension, if present, to determine client
preferences and MUST only select a version of TLS present in that
extension.  They MUST ignore any unknown versions.  If the extension
is not present, they MUST negotiate TLS 1.2 or prior as specified in
RFC5246, even if ClientHello.version is {3, 4} or later.
Paragraph (version B):
Servers which are compliant with this specification MUST use only the
"supported_versions" extension, if present, to determine client
preferences and MUST only select a version of TLS present in that
extension.  They MUST ignore any unknown versions.  If the extension
is not present, they MUST negotiate TLS 1.2 or prior as specified in
RFC5246, even if ClientHello.legacy_version is {3, 4} or later.
Draft: draft-ietf-tls-tls13

Commentary: By the way , you also need to update Version Negotiation section of the . 
 lgtm 
 Done ,   wrote :
Paragraph (version B):
While the eventual version indicator for the RFC version of TLS 1.3
will be {3, 4}, implementations of draft versions of this
specification SHOULD instead advertise {0x7f, [draft-version]} in
their "supported_versions" extension, in ServerHello.version, and
HelloRetryRequest.server_version.  This allows pre-RFC
implementations to safely negotiate with each other, even if they
would otherwise be incompatible.
Draft: draft-ietf-tls-tls13

Commentary: Avoid both starting with an existing hash AND ending with an existing SignatureAlgorithm . In principle , this should not be necessary , but TLS 2 says : Bouncy Castle appears to have been enforcing this , causing interop issues . As this was a straight - up MUST NOT , it seems prudent to renumber . And if we 're renumbering anyway , may as well avoid all the old SignatureAlgorithms and avoid confusing tools like Wireshark .
Paragraph (version A):
TLS SignatureScheme Registry: Values with the first byte in the
range 0-254 (decimal) are assigned via Specification Required
RFC2434.  Values with the first byte 255 (decimal) are reserved
for Private Use RFC2434.  This registry SHALL have a "Recommended"
column.  The registry [shall be/ has been] initially populated
with the values described in signature-algorithms.  The following
values SHALL be marked as "Recommended": ecdsa_secp256r1_sha256,
ecdsa_secp384r1_sha384, rsa_pss_sha256, rsa_pss_sha384,
rsa_pss_sha512, ed25519.
Paragraph (version B):
TLS SignatureScheme Registry: Values with the first byte in the
range 0-254 (decimal) are assigned via Specification Required
RFC2434.  Values with the first byte 255 (decimal) are reserved
for Private Use RFC2434.  Values with the first byte in the range
0-6 or with the second byte in the range 0-3 that are not
currently allocated are reserved for backwards compatibility.
This registry SHALL have a "Recommended" column.  The registry
[shall be/ has been] initially populated with the values described
in signature-algorithms.  The following values SHALL be marked as
"Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384,
rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519.
Draft: draft-ietf-tls-tls13

Commentary: We are inconsistent about " AEAD cipher " and " AEAD algorithm " . RFC 5116 uses " AEAD algorithm " and " AEAD cipher " is confusing with " cipher suite " , so standardize on algorithm . IANA considerations were never updated to actually add the cipher suites . Fix that . Match the cipher suite name column with the IANA name so we can reuse the table . Finally , since we are defining new cipher suites , we should take care to cite where our AEADs come from . Do so .
Paragraph (version A):
IANA [SHALL add/has added] the cipher suites listed in cipher-
suites to the registry.  The "Value" and "Description" columns are
taken from the table.  The "DTLS-OK" column is marked as "Yes".
Paragraph (version A):
Cipher suites marked as "Yes" are those allocated via Standards
Track RFCs.  Cipher suites marked as "No" are not; cipher
suites marked "No" range from "good" to "bad" from a
cryptographic standpoint.
Draft: draft-ietf-tls-tls13

Commentary: TLS still permits shared point negotiation via ECDH , TLS 1.3 removes point format negotiation .
Paragraph (version A):
Note: Versions of TLS prior to 1.3 permitted point negotiation; TLS
curve.
Paragraph (version B):
Note: Versions of TLS prior to 1.3 permitted point format
negotiation; TLS 1.3 removes this feature in favor of a single point
format for each curve.
Draft: draft-ietf-tls-tls13

Commentary: This seems to have just been a mistake ? Unlike ALPN , servername is n't a value that is selected by the server , so there 's no need to match it against a value stored in the session . There is the issue of whether sessions are resumable across names or other application - level contexts ( for instance , whether we send client certificates , different cipher profiles , etc . ) , but that is a more complex issue than simply matching on servername on the server side . Moreover , any rules there would want to apply to resumption as a whole . It seems there 's no reason to have 0 - RTT - specific rules over resumption ones here .
Paragraph (version A):
The server_name RFC6066 value provided by the client, if any.
Draft: draft-ietf-tls-tls13

Commentary: since server hello says that presence of extra extensions is a illegalparameter and encrypted extensions say that presence of server hello specific extensions is illegalparameter there is no reason to specify what to do with situation that MUST generate fatal alert
Paragraph (version A):
The same extension types MUST NOT appear in both the ServerHello and
EncryptedExtensions.  If the same extension appears in both
locations, the client MUST rely only on the value in the
EncryptedExtensions block.  All server-sent extensions other than
those explicitly listed in server-hello or designated in the IANA
registry MUST only appear in EncryptedExtensions.  Extensions which
are designated to appear in ServerHello MUST NOT appear in
EncryptedExtensions.  Clients MUST check EncryptedExtensions for the
presence of any forbidden extensions and if any are found MUST
terminate the handshake with an "illegal_parameter" alert.
Paragraph (version B):
The same extension types MUST NOT appear in both the ServerHello and
EncryptedExtensions.  All server-sent extensions other than those
explicitly listed in server-hello or designated in the IANA registry
MUST only appear in EncryptedExtensions.  Extensions which are
designated to appear in ServerHello MUST NOT appear in
EncryptedExtensions.  Clients MUST check EncryptedExtensions for the
presence of any forbidden extensions and if any are found MUST
terminate the handshake with an "illegal_parameter" alert.
Draft: draft-ietf-tls-tls13

Commentary: reading standards is hard enough without use of advanced English , use simple words
Paragraph (version A):
Under-specified types (opaque, variable-length vectors, and
structures that contain opaque) cannot be assigned values.  No fields
of a multi-element structure or vector may be elided.
Paragraph (version B):
Under-specified types (opaque, variable-length vectors, and
structures that contain opaque) cannot be assigned values.  No fields
of a multi-element structure or vector may be omitted.
Draft: draft-ietf-tls-tls13

Commentary: the renegotiation mechanism from TLSv1.2 and earlier is deprecated , that deprecation extends to the ability to renegotiate existing TLSv1.2 ( or earlier ) session to TLSv1.3 
 Sorry , but I just realized you ca n't do this . You need to prohibit negotiating back up to 1.3 , but the client has to be able to offer 1.3 . Here 's the Bugzilla thread on this 
 so the client MAY send a TLSv1.3 Client Hello in a TLSv1.2 session , but server MUST NOT negotiate TLSv1.3 then ? 
 How about this ? 
 OpenSSL derived implementations do n't even allow you to switch versions on  at all because that would be insane . We do send the higher ClientHello version for the reasons EKR pointed out , but the ServerHello version must match . I would actually argue that it is fair game to assume version - related things are implicitly forked and locked ( a 1.1 session implicitly can not be resumed at 1.2 , etc . ) , but the spec should be much clearer on this , so saying it explicitly now is a good idea . 
 Yes . ,   wrote : 
 I agree , resuming sessions must be at the same version and text saying so is a good idea . 
 This is actually about negotiating at TLS 1.2 and then renegotiating to TLS 1.3 . It 's not clear how you would even manage to resume a TLS 1.2 session at TLS 1.3 or vice versa , but explicit text to this effect would be good . It has certainly historically been a mess . 
 OK , that should fix all the comments . 
 Merged . please send me a PR adding yourself to Contributors 
 here it is :
Paragraph (version B):
If a server established a TLS session at a previous version of the
protocol and receives a TLS 1.3 ClientHello in a renegotiation, it
MUST retain the previous protocol version.  In particular, it MUST
NOT negotiate TLS 1.3.  A client that receives a TLS 1.3 ServerHello
in an established session MUST send a fatal "protocol_version" alert
and close the connection.
Draft: draft-ietf-tls-tls13

Commentary: It looks like this is carried over from TLS 1.2 - --seems I was wrong and TLS 1.2 did actually say whether there were leading zeros in front of DHE parameters --- but I believe it is no longer used . Instead our crypto primitives all act on byte strings . Any conversion between byte strings and the primitive 's internal structures is handled by the primitive itself . ( RFC 7748 natively acts on byte strings , 1 specifies how FFDHE is encoded , RSA - PSS comes with a byte string form , etc . )
Paragraph (version A):
Note that in some cases (e.g., DH parameters) it is necessary to
represent integers as opaque vectors.  In such cases, they are
represented as unsigned integers (i.e., additional leading zero
octets are not used even if the most significant bit is set).
Draft: draft-ietf-tls-tls13

Commentary: No context and empty context are now declared to be the same . Add some ALL CAPS WORDS for future specifications to deprecate no context . I used SHOULD to forbid no context because , if some protocol currently uses no context , switching it to empty context is a breaking change and probably not worth it . We just want new ones to always provide a context . This affects the rules for using exporters , so RFC 5705 is to the list of updated documents . Closes issue .
Paragraph (version B):
Note that providing no context computes the same value as providing
an empty context.  As of this document's publication, no allocated
exporter label is used with both modes.  Future specifications MUST
NOT provide an empty context and no context with the same label and
SHOULD provide a context, possibly empty, in all exporter
computations.