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

Commentary: I believe we are asking IANA to also update all references to " this RFC " .
Paragraph (version B):
IANA [shall update/has updated] the TLS registries to reference this
document.
Draft: draft-ietf-tls-rfc8446bis

Commentary: To keep the text in 8446bis and to avoid having people to read 8446 ( and address the OPEN issues ) in the IANA Considerations section - from IANA : If you want to keep the old actions in the document , we ’d like to see those actions preceded by an introduction or sub - section ( or more than one sub - section ; however it ’s appropriate to structure it ) that tells us what the new actions are for this document . 
 The diffs are informative here - I think there 's only adding general_error to TLS Alerts and updating the references to RFC 8446bis vice RFC 8446 . 
 Apologies for any confusion - already address via .
Paragraph (version B):
This document uses several registries that were originally created in
RFC4346 and updated in RFC8446 and RFC8447.  The changes between
RFC8446 and RFC8447 this document are described in bis-changes.  IANA
has updated these to reference this document.
Paragraph (version B):
IANA [shall rename/has renamed] the "extended_master_secret" value in
the TLS ExtensionType Values registry to "extended_main_secret".
Draft: draft-ietf-tls-rfc8446bis

Commentary: but tell receiving implementations not to enforce them . This addresses . PTAL . 
 Limits on Key Usage ( Section 5.5 ): Since key updates are necessary for security , I think MUST ( rather than SHOULD ) is appropriate . ( And similarly in the sentence that follows : " Note that it is not possible to perform a KeyUpdate for early data and therefore implementations SHOULD not exceed the limits when sending early data . " ) 
 IIRC there was a disagreement on when the rekeying should happen , and more specifically , the limits for Chacha20 - Poly1305 are higher than the limit imposed by TLS sequence numbers , so there 's no need to rekey if all you support is Chacha20 ... 
 That seems compatible with MUST : Section 5.5 also notes : It follows that implementations might not do a key update . 
 I do n't necessarily object to a MUST but I think as with the limit on KeyUpdate it would need to be paired with a MUST NOT enforce on the receiver . As I understand it , these bounds are n't necessarily tight , so we might have some results that allowed fewer rekeys in the future .
Paragraph (version A):
There are cryptographic limits on the amount of plaintext which can
be safely encrypted under a given set of keys.  AEAD-LIMITS provides
an analysis of these limits under the assumption that the underlying
primitive (AES or ChaCha20) has no weaknesses.  Implementations
SHOULD do a key update as described in key-update prior to reaching
these limits.  Note that it is not possible to perform a KeyUpdate
for early data and therefore implementations SHOULD not exceed the
limits when sending early data.
Paragraph (version B):
There are cryptographic limits on the amount of plaintext which can
be safely encrypted under a given set of keys.  AEAD-LIMITS provides
an analysis of these limits under the assumption that the underlying
primitive (AES or ChaCha20) has no weaknesses.  Implementations MUST
either close the connection or do a key update as described in key-
update prior to reaching these limits.  Note that it is not possible
to perform a KeyUpdate for early data and therefore implementations
MUST not exceed the limits when sending early data.  Receiving
implementations SHOULD NOT enforce these limits, as future analyses
may result in updated values.
Draft: draft-ietf-tls-rfc8446bis

Commentary: The last few years I have personally experienced several occasions where people in SDOs as well as developers believe that TLS magically gives them authentication . This has resulted in security standards that just writes that " TLS is used for mutual authentication " without any more details as well as implementations that do not provide any identity verification at all and instead just doing a full path validation , when they should have checked the server identity , that the right trust anchor was used , and that the right intermediate CA was used . I think this is a common problem . Reading RFC8446 , I think it is quite easy for people without expertise in security protocols to get the understanding that TLS gives you authentication . Suggestions : think RFC8446 should be clearer with that what is provided by the TLS protocol is transport of authentication credentials and proof - of - possession of the private authentication key . think the requirements on the application using TLS should be clearer . Maybe : " Application protocols using TLS MUST specify how to initiate TLS handshaking , how to do path validation , and how to do identity verification . " I think it would be very good for readers if draft - ietf - uta - rfc6125bis was given as an informative reference .
Paragraph (version A):
TLS is application protocol independent; higher-level protocols can
layer on top of TLS transparently.  The TLS standard, however, does
not specify how protocols add security with TLS; how to initiate TLS
handshaking and how to interpret the authentication certificates
exchanged are left to the judgment of the designers and implementors
of protocols that run on top of TLS.
Paragraph (version B):
TLS is application protocol independent; higher-level protocols can
layer on top of TLS transparently.  The TLS standard, however, does
not specify how protocols add security with TLS; how to initiate TLS
handshaking and how to interpret the authentication certificates
exchanged are left to the judgment of the designers and implementors
of protocols that run on top of TLS.  Application protocols using TLS
MUST specify how TLS works with their application protocol, including
how and when handshaking occurs, and how to do identity verification.
I-D.ietf-uta-rfc6125bis provides useful guidance on integrating TLS
with applicaiton protocols.
Draft: draft-ietf-tls-rfc8446bis

Commentary: closenotify has always used a warning alert level , but this is not actually written down anywhere . It seems to have gotten lost as early as RFC 4346 ( TLS 1.1 ! ) . In RFC 2246 , there is some text that mentions the correct level is warning as an aside in describing something else . I was n't able to find any other text that discussed this . Then , RFC 4346 dropped the session termination behavior : But in doing so , it dropped any mention of which alert level to use . That text has carried over to RFC 8446 as : In RFC 8446 , we said alert levels no longer matter and can be " safely ignored " , but this still leaves unspecified what the sender should do . Skimming implementations , both BoringSSL and NSS will treat " fatal " closenotify as an error , so using " warning " is also necessary for interop .
Paragraph (version A):
This alert notifies the recipient that the sender will not send
any more messages on this connection.  Any data received after a
closure alert has been received MUST be ignored.
Paragraph (version B):
This alert notifies the recipient that the sender will not send
any more messages on this connection.  Any data received after a
closure alert has been received MUST be ignored.  This alert MUST
be sent with AlertLevel=warning.
Draft: draft-ietf-tls-rfc8446bis

Commentary: MGF1 got unhelpfully spelled out as " mask generation function 1 " in RFC 8446 . I 'm guessing this is the result of an acronym expansion editting pass , but the function is simply called " MGF1 " . There is no such thing as " mask generation function 1 " . Correct this back to MGF1 . In hopes this does n't get hit the same editing pass later , I 've tweaked the wording and moved the citation so that " mask generation function " is still uttered before MGF1 , and it 's clearer that both primitives are defined in RFC 8017 .
Paragraph (version A):
Indicates a signature algorithm using RSASSA-PSS RFC8017 with mask
generation function 1.  The digest used in the mask generation
function and the digest being signed are both the corresponding
hash algorithm as defined in SHS.  The length of the Salt MUST be
equal to the length of the output of the digest algorithm.  If the
public key is carried in an X.509 certificate, it MUST use the
rsaEncryption OID RFC5280.
Paragraph (version A):
Indicates a signature algorithm using RSASSA-PSS RFC8017 with mask
generation function 1.  The digest used in the mask generation
function and the digest being signed are both the corresponding
hash algorithm as defined in SHS.  The length of the Salt MUST be
equal to the length of the digest algorithm.  If the public key is
carried in an X.509 certificate, it MUST use the RSASSA-PSS OID
RFC5756.  When used in certificate signatures, the algorithm
parameters MUST be DER encoded.  If the corresponding public key's
parameters are present, then the parameters in the signature MUST
be identical to those in the public key.
Paragraph (version B):
Indicates a signature algorithm using RSASSA-PSS with a mask
generation function of MGF1, as defined in RFC8017.  The digest
used in MGF1 and the digest being signed are both the
corresponding hash algorithm as defined in SHS.  The length of the
Salt MUST be equal to the length of the output of the digest
algorithm.  If the public key is carried in an X.509 certificate,
it MUST use the rsaEncryption OID RFC5280.
Paragraph (version B):
Indicates a signature algorithm using RSASSA-PSS with a mask
generation function of MGF1, as defined in RFC8017.  The digest
used in MGF1 and the digest being signed are both the
corresponding hash algorithm as defined in SHS.  The length of the
Salt MUST be equal to the length of the digest algorithm.  If the
public key is carried in an X.509 certificate, it MUST use the
RSASSA-PSS OID RFC5756.  When used in certificate signatures, the
algorithm parameters MUST be DER encoded.  If the corresponding
public key's parameters are present, then the parameters in the
signature MUST be identical to those in the public key.
Draft: draft-ietf-tls-rfc8446bis

Commentary: PTAL . 
 can you read ?
Paragraph (version A):
Implementations MUST NOT send extension responses if the remote
endpoint did not send the corresponding extension requests, with the
exception of the "cookie" extension in the HelloRetryRequest.  Upon
receiving such an extension, an endpoint MUST abort the handshake
with an "unsupported_extension" alert.
Paragraph (version B):
Implementations MUST NOT send extension responses (i.e., in the
ServerHello, EncryptedExtensions, HelloRetryRequest, and Certificate
messages) if the remote endpoint did not send the corresponding
extension requests, with the exception of the "cookie" extension in
the HelloRetryRequest.  Upon receiving such an extension, an endpoint
MUST abort the handshake with an "unsupported_extension" alert.
Draft: draft-ietf-tls-rfc8446bis

Commentary: The new CFRG curves will probably have different point formats . 
 This was decided and will be handled as part of import
Paragraph (version A):
This alert notifies the recipient that the sender is canceling the
handshake for some reason unrelated to a protocol failure.  If a
user cancels an operation after the handshake is complete, just
closing the connection by sending a "close_notify" is more
appropriate.  This alert SHOULD be followed by a "close_notify".
This alert generally has AlertLevel=warning.
Paragraph (version A):
Either party MAY initiate a close of its write side of the connection
by sending a "close_notify" alert.  Any data received after a closure
alert has been received MUST be ignored.  If a transport-level close
is received prior to a "close_notify", the receiver cannot know that
all the data that was sent has been received.
Paragraph (version B):
This alert notifies the recipient that the sender is canceling the
handshake for some reason unrelated to a protocol failure.  If a
user cancels an operation after the handshake is complete, just
closing the connection by sending a "close_notify" is more
appropriate.  This alert MUST be followed by a "close_notify".
This alert generally has AlertLevel=warning.  Receiving
implementations should continue to read data from the peer until a
"close_notify" is received, though they MAY log or otherwise
record them.
Paragraph (version B):
Either party MAY initiate a close of its write side of the connection
by sending a "close_notify" alert.  Any data received after a
"close_notify" alert has been received MUST be ignored.  If a
transport-level close is received prior to a "close_notify", the
receiver cannot know that all the data that was sent has been
received.
Draft: draft-ietf-tls-rfc8446bis

Commentary: Note that this is precisely the language that appears in 9147 . 
 I made some updates , and am just merging in anticipation of the draft deadline . Feel free to file a PR if you think changes are indicated . 
 In we some text to DTLS about how rekeying too many times ( 2 ^ 64 is allowed with the 64 - bit DTLS 1.3 epoch ) risks key reuse within a connection , and accompanied it with a MUST NOT guidance to rekey more than 2 ^ 48 times ( but receivers MUST NOT enforce the rule ) ; this overrides the usual MUST - level requirement to match an " update_requested " KeyUpdate with another KeyUpdate before sending more data . It seems that some similar considerations apply for non - D TLS as well .
Paragraph (version B):
With a 128-bit key as in AES-128, rekeying 2^64 times has a high
probability of key reuse within a given connection.  Note that even
if the key repeats, the IV is also independently generated, so the
chance of a joint key/IV collision is much lower.  In order to
provide an extra margin of security, sending implementations MUST NOT
allow the epoch - and hence the number of key updates - to exceed
2^48-1.  In order to allow this value to be changed later - for
instance for ciphers with more than 128-bit keys - receiving
implementations MUST NOT enforce this rule.  If a sending
implementation receives a KeyUpdate with request_update set to
"update_requested", it MUST NOT send its own KeyUpdate if that would
cause it to exceed these limits and SHOULD instead ignore the
"update_requested" flag.  This may result in an eventual need to
terminate the connection when the limits in limits-on-key-usage are
reached.
Draft: draft-ietf-tls-rfc8446bis

Commentary: I can not find any specification in RFC8446 of which key is used to encrypt an alert or heartbeat sent before Finished ( I assume it is the applicationtrafficsecret ) . It is definitly possible that this information is somewhere in the document and that I just do not find it . The document seems to treat " record type " and " content type " as synonyms . Are both terms needed ? I would suggest updating table in section 7.3 to make it complete . Record type " Application Data " should probably be everything that is not a Handshake . It would be good to say something about post - handshake messages in section 7.3 . Post - handshake messages have record type / content type Handshake but does not follow what the table in 7.3 says . 
 The key is not specified as some errors can make it impossible for the peer to send an alert under specific key , so the used key is implicit — the currently used one , whichever it happens to be , including plaintext . 
 True , thank for reminding me . That is quite simple . Given that , I think the table in Section 7.3 is confusing and and not even correct . It claims to give the secret for each record type , but only lists 2 . " 0 - RTT Application " is not a record type ..... It gives the idea that the secret follows from the record type , which is not correct . It claims that record type Handshake is protected with [ sender]handshaketraffic_secret , but record type handshake is protected with all three secrets depending on the state . I think it would probably be better to remove the table in 7.3 than to keep the current version . Even better would be to replace 7.3 with a more correct description .
Paragraph (version A):
All the traffic keying material is recomputed whenever the underlying
Secret changes (e.g., when changing from the handshake to Application
Data keys or upon a key update).
Paragraph (version B):
Alerts are sent with the then current sending key (or as plaintext if
no such key has been established.)  All the traffic keying material
is recomputed whenever the underlying Secret changes (e.g., when
changing from the handshake to Application Data keys or upon a key
update).
Draft: draft-ietf-tls-rfc8446bis

Commentary: I think this is what we want here .
Paragraph (version B):
Note that RFC8996 and backward-compatibility-security forbid the
negotation of TLS versions below 1.2; implementations which do not
follow that guidance MUST behave as described above.
Draft: draft-ietf-tls-rfc8446bis

Commentary: The paragraph " This document supersedes and obsoletes previous " in the introduction also needs to be updated ...
Paragraph (version A):
This document updates RFCs 5705 and 6066 and obsoletes RFCs 5077,
5246, and 6961.  This document also specifies new requirements for
TLS 1.2 implementations.
Paragraph (version B):
This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes
RFCs 5077, 5246, 6961, and 8446.  This document also specifies new
requirements for TLS 1.2 implementations.
Draft: draft-ietf-tls-rfc8446bis

Commentary: I was n't sure where to put this text . There was an  talking about TLS 1.2 , so I figured it could go nearby . And then it probably wanted to go before that  so there is n't ambiguity about how to refer to EMS . 
 Implementations of TLS 1.2 will remain for some time . The document renames " master secret " to " main secret " , but TLS 1.2 has some naming variations that are n't in TLS 1.3 . Perhaps a section in the document somewhere ( maybe under  Compatibility since that talks about older versions ) that describes some additional deltas : " master secret " = " main secret " , to align this this document " premaster secret " = " preliminary secret " ( " pre - main secret " sounds weird to me ) " extended master secret " = " extended main secret " ( probably move rfc7627 from informative to normative and then also add to the updates line ) Also cover the variations like " EncryptedPreMasterSecret " and " mastersecret " , but not the KDF labels since those ca n't change . And then IANA considerations to rename extendedmastersecret to extendedmain_secret in the registries .
Paragraph (version B):
The term "master" as applied to secrets has been removed, and the
"extended_master_secret" extension RFC7627 has been renamed to
"extended_main_secret".
Draft: draft-ietf-tls-tls13

Commentary: in section 4.2.10
Paragraph (version A):
Ignore the extension and return a regular 1-RTT response.  The
server then skips past early data by attempting to deprotect
received records using the handshake traffic key, discarding
records which fail deprotection (up to the configured
max_early_data_size).  Once a record is deprotected successfully,
it is treated as the start of the client's second flight and the
the server proceeds as with an ordinary 1-RTT handshake.
Paragraph (version B):
Ignore the extension and return a regular 1-RTT response.  The
server then skips past early data by attempting to deprotect
received records using the handshake traffic key, discarding
records which fail deprotection (up to the configured
max_early_data_size).  Once a record is deprotected successfully,
it is treated as the start of the client's second flight and the
server proceeds as with an ordinary 1-RTT handshake.
Draft: draft-ietf-tls-tls13

Commentary: Add missing brace for first paragraph of 4.6.1 .
Paragraph (version A):
At any time after the server has received the client Finished
message, it MAY send a NewSessionTicket message.  This message
creates a unique association between the ticket value and a secret
PSK derived from the resumption master secret (see cryptographic-
computations.
Paragraph (version B):
At any time after the server has received the client Finished
message, it MAY send a NewSessionTicket message.  This message
creates a unique association between the ticket value and a secret
PSK derived from the resumption master secret (see cryptographic-
computations).
Draft: draft-ietf-tls-tls13

Commentary: As naïve handling of external identities may cause the server to be vulnerable to identity enumeration attacks , refer the section that discusses that danger in the PSK section itself .
Paragraph (version A):
Prior to accepting PSK key establishment, the server MUST validate
the corresponding binder value (see psk-binder below).  If this value
is not present or does not validate, the server MUST abort the
handshake.  Servers SHOULD NOT attempt to validate multiple binders;
rather they SHOULD select a single PSK and validate solely the binder
that corresponds to that PSK.  See [client-hello-recording] for the
security rationale for this requirement.  In order to accept PSK key
establishment, the server sends a "pre_shared_key" extension
indicating the selected identity.
Paragraph (version B):
Prior to accepting PSK key establishment, the server MUST validate
the corresponding binder value (see psk-binder below).  If this value
is not present or does not validate, the server MUST abort the
handshake.  Servers SHOULD NOT attempt to validate multiple binders;
rather they SHOULD select a single PSK and validate solely the binder
that corresponds to that PSK.  See [client-hello-recording] and [psk-
identity-exposure] for the security rationale for this requirement.
In order to accept PSK key establishment, the server sends a
"pre_shared_key" extension indicating the selected identity.
Draft: draft-ietf-tls-tls13

Commentary: We should say something about whether the same OID is allowed to appear multiple times in the oid_filters extension ( and if it is , what the semantics are ) . Extracted from 
 As noted in my comments , there is a natural semantic for multiple , but it seems a bit silly . I think it would be fine to forbid them , though . 
 I think it 's OK to limit to one appearance of a given OID in the oid_filters . ( It probably does not matter much in terms of code complexity either way . ) 
 I 'm inclined to limit to one appearance of a given OID in oid_filters . 
 I guess it 's implicit that there is no meaning to the order in which oid / values appear , and we do n't need to say anything about that .
Paragraph (version A):
"unsupported_certificate" alert.
Paragraph (version B):
"unsupported_certificate" alert.  Any given OID MUST NOT appear
more than once in the filters list.
Draft: draft-ietf-tls-tls13

Commentary: ClientHello , etc . , processing rules are in earlier versions too . We 're just calling out some corollaries of it all .
Paragraph (version A):
This section describes invariants that TLS endpoints and middleboxes
MUST follow.  It also applies to earlier versions, which assumed
these rules but did not document them.
Paragraph (version B):
This section describes invariants that TLS endpoints and middleboxes
MUST follow.  It also applies to earlier versions of TLS.