jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-tls-md5-sha1-deprecate-08

Commentary: Addressing this . PTAL 
 I am really growing to dislike these " here is the alert you must use " constructions . Are they necessary ?
Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages.
If no other signature algorithms are available (for example, if the
client does not send a signature_algorithms extension), the server
MUST abort the handshake with a handshake_failure alert or select a
different cipher suite.
Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages.
If a server receives a CertificateVerify message with MD5 or SHA-1 it
MUST abort the connection with handshake_failure or
insufficient_security alert.
Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages.
If the client receives a ServerKeyExchange message indicating MD5 or
SHA-1, then it MUST abort the connection with an illegal_parameter
alert.
Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages.
If a server receives a CertificateVerify message with MD5 or SHA-1 it
MUST abort the connection with an illegal_parameter alert.
Draft: draft-ietf-tls-md5-sha1-deprecate-07

Commentary: cc 
 I believe this I - D should still include the " update : 5246 ( if approved ) " header , even though we took out the 5246 OLD / NEW section . We are still proposing that 5246 be changed to require signature_algorithms extension be sent and that MD5 / SHA1 never be sent . In other words , I think you can merge this PR assuming there are no conflicts . 
 Verifying that this is okay on list , but  suggested the following change for s6 : Add the following immediately bfore the OLD / NEW , i.e. , right after " due to MD5 and SHA-1 being deprecated . " : In Section 7.1.4.1 : the following text is removed : If the client supports only the default hash and signature algorithms ( listed in this section ) , it MAY omit the signature_algorithms extension . 
 Resulted in a number of changes - see . 
 I think you also need to update the abstract and introduction sections , as they both mention " This document updates ... " ( same as ) . Will probably conflict with so we should merge that first . I believe this can be merged as is . I.e. , do n't remove the " udpates " header , change the abstract , or intro .
Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms
extension.  If a client does not send a signature_algorithms
extension, then the server MUST abort the handshake and send a
handshake_failure alert, except when digital signatures are not used
(for example, when using PSK ciphers).
Clients MUST include the signature_algorithms extension.  Clients
MUST NOT include MD5 and SHA-1 in this extension.
Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages.
If a client receives a MD5 or SHA-1 signature in a ServerKeyExchange
message it MUST abort the connection with the illegal_parameter
alert.
Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages.
If no other signature algorithms are available (for example, if the
client does not send a signature_algorithms extension), the server
MUST abort the handshake with a handshake_failure alert or select a
different cipher suite.
RFC5246, The Transport Layer Security (TLS) Protocol Version 1.2,
suggests that implementations can assume support for MD5 and SHA-1 by
their peer.  This update changes the suggestion to assume support for
SHA-256 instead, due to MD5 and SHA-1 being deprecated.
Draft: draft-ietf-tls-md5-sha1-deprecate-07

Commentary: I did n't add a -08 version of the doc ( datatracker keeps that history ) , and this keeps the diff smaller . cc 
 Should we remove the 7525 text now that 7525bis is underway . 
 Could you also : remove the reference to 7525 on line 14 drop 7525 from line 45 , i.e. , change the header . This I - D will no longer update the 7525 . drop " and RFC 7525 " line 137 . drop " and < xref target="RFC7525 " / " from line 158 Like
The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to
attack and this document deprecates their use in TLS 1.2 digital
signatures.  However, this document does not deprecate SHA-1 in HMAC
for record protection.  This document updates RFC 5246 and RFC 7525.
The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to
attack and this document deprecates their use in TLS 1.2 digital
signatures.  However, this document does not deprecate SHA-1 in HMAC
for record protection.  This document updates RFC 5246.
attacks were practical.  This document updates RFC5246 and RFC7525 in
such a way that MD5 and SHA-1 MUST NOT be used for digital
signatures.  However, this document does not deprecate SHA-1 in HMAC
for record protection.  Note that the CABF has also deprecated use of
SHA-1 CABF.
attacks were practical.  This document updates RFC5246 in such a way
that MD5 and SHA-1 MUST NOT be used for digital signatures.  However,
this document does not deprecate SHA-1 in HMAC for record protection.
Note that the CABF has also deprecated use of SHA-1 CABF.
RFC7525, Recommendations for Secure Use of Transport Layer Security
(TLS) and Datagram Transport Layer Security (DTLS), recommends use of
SHA-256 as a minimum requirement.  This update moves the minimum
recommendation to use stronger language deprecating use of both SHA-1
and MD5.  The prior text did not explicitly include MD5 or SHA-1; and
this text adds guidance to ensure that these algorithms have been
deprecated.
When using RSA, servers SHOULD authenticate using certificates with
at least a 2048-bit modulus for the public key.  In addition, the use
of the SHA-256 hash algorithm is RECOMMENDED (see CAB-Baseline for
more details).  Clients SHOULD indicate to servers that they request
SHA-256, by using the "Signature Algorithms" extension defined in TLS
1.2.
Servers SHOULD authenticate using certificates with at least a
2048-bit modulus for the public key.
In addition, the use of the SHA-256 hash algorithm is RECOMMENDED;
and SHA-1 or MD5 MUST NOT be used (see CAB-Baseline for more
details).  Clients MUST indicate to servers that they request SHA-
256, by using the "Signature Algorithms" extension defined in TLS
1.2.
Draft: draft-ietf-tls-md5-sha1-deprecate-02

Commentary: thanks , updated with the additional changes . 
 Feel free to merge when you get a chance 
 Great ! Now on to Daniel 's comments .
The MD5 and SHA-1 hashing algorithms are steadily weakening in
strength and their deprecation process should begin for their use in
TLS 1.2 digital signatures.  However, this document does not
deprecate SHA-1 in HMAC for record protection.  This document updates
RFC 5246 and RFC 7525.
The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to
attack and this document deprecates their use in TLS 1.2 digital
signatures.  However, this document does not deprecate SHA-1 in HMAC
for record protection.  This document updates RFC 5246 and RFC 7525.
RFC7525, Recommendations for Secure Use of Transport Layer Security
(TLS) and Datagram Transport Layer Security (DTLS) recommends use of
SHA-256 as a minimum requirement.  This update moves the minimum
recommendation to use stronger language deprecating use of both SHA-1
and MD5.  The prior text did not explicitly include MD5 or SHA-1; and
this text adds guidance to ensure that these algorithms have been
deprecated..
RFC7525, Recommendations for Secure Use of Transport Layer Security
(TLS) and Datagram Transport Layer Security (DTLS) recommends use of
SHA-256 as a minimum requirement.  This update moves the minimum
recommendation to use stronger language deprecating use of both SHA-1
and MD5.  The prior text did not explicitly include MD5 or SHA-1; and
this text adds guidance to ensure that these algorithms have been
deprecated.
Other entries of the resgistry remain the same.
Concerns with TLS 1.2 implementations falling back to SHA-1 is an
issue.  This draft updates the TLS 1.2 specification to deprecate
support for MD5 and SHA-1 for digital signatures.  However, this
document does not deprecate SHA-1 in HMAC for record protection.
Other entries of the registry remain the same.
Concerns with TLS 1.2 implementations falling back to SHA-1 is an
issue.  This document updates the TLS 1.2 specification to deprecate
support for MD5 and SHA-1 for digital signatures.  However, this
document does not deprecate SHA-1 in HMAC for record protection.
Draft: draft-ietf-tls-md5-sha1-deprecate-02

Commentary: SHA-1 entries in the signature scheme registry should not be recommended this pull request creates an IANA considerations section to remove the recommended status . 
 Partially addresses . 
 Please address the following IDNits : -- The document seems to lack an IANA Considerations section . ( See Section 2.2 of for how to handle the case when there are no actions for IANA . ) -- The draft header indicates that this document updates  , but the abstract does n't seem to mention this , which it should . -- The draft header indicates that this document updates RFC7525 , but the abstract does n't seem to mention this , which it should . Section 1 . Editorial . -- s / RFC 5246 [  -- s / RFC 6151 [ RFC6151]/[RFC6151]/ -- s / RFC7525 [ RFC7525]/[RFC7525]/ Section 1 . Editorial . For symmetry with the rest of the text : OLD RFC 6151 [ RFC6151 ] details the security considerations , including collision attacks for MD5 , published in 2011 . NEW In 2011 , [ RFC6151 ] detailed the security considerations , including collision attacks for MD5 . Section 1 . Please provide a reference for "  , et   . Is there a reference to provide for the " the potential for brute - force attack " Section 6 .   . s / RFC5246 [ RFC5246]/[RFC5246]/ Section 6 . Move the text " In Section 7.4.1.4.1 : the text should be revised from " out of the " OLD " block of text to be its own intro paragraph so that the OLD vs. NEW is a clear cut - and - paste . Section 7 . Editorial . s/ RFC7525 [ RFC7525]/[RFC7525]/ Section 7 . SHA-1 is also not mentioned in RFC7525 . Recommend : OLD The prior text did not explicitly include MD5 and this text adds it to ensure it is understood as having been deprecated . NEW The prior text did not explicitly include MD5 or SHA-1 ; and this text adds guidance to ensure that these algorithms have been deprecated . Section 7 . Editorial .  . OLD In addition , the use of the SHA-256 hash algorithm is RECOMMENDED , SHA-1 or MD5 MUST NOT be used NEW In addition , the use of the SHA-256 hash algorithm is RECOMMENDED ; and SHA-1 or MD5 MUST NOT be used Section 10.2 Please make  a normative reference . 
 This looks good to merge !
Other entries of the resgistry remain the same.
Draft: draft-ietf-tls-md5-sha1-deprecate-02

Commentary: As per discussion on mailing list . 
 can you please float this change on the mailing list ?
RFC5246 and RFC7525 in such as way that MD5 and SHA-1 MUST NOT be
used for digital signatures.  However, this document does not
deprecate SHA-1 in HMAC for record protection.
RFC5246 and RFC7525 in such a way that MD5 and SHA-1 MUST NOT be used
for digital signatures.  However, this document does not deprecate
SHA-1 in HMAC for record protection.
Clients SHOULD NOT include MD5 and SHA-1 in the signature_algorithms
extension.  If a client does not send a signature_algorithms
extension, then the server MUST abort the handshake and send a
handshake_failure alert, except when digital signatures are not used
(for example, when using PSK ciphers).
Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms
extension.  If a client does not send a signature_algorithms
extension, then the server MUST abort the handshake and send a
handshake_failure alert, except when digital signatures are not used
(for example, when using PSK ciphers).
Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest
message.
Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange message.
If client does receive a MD5 or SHA-1 signature in the
ServerKeyExchange message and it sent one in signature_algorithms
extensions it MUST abort the connection with handshake_failure or
insufficient_security alert.  If client did not send MD5 nor SHA-1
hash algorithm in signature_algorithms extension and it receives a
MD5 or SHA-1 signature in the ServerKeyExchange it MUST abort the
connection with the illegal_parameter alert.
Clients MUST NOT include MD5 and SHA-1 in CertificateVerify message.
If the server receives a CertificateVerify message with MD5 or SHA-1
it MUST abort the connection with handshake_failure or
insufficient_security alert.
Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest
messages.
Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages.
If a client receives a MD5 or SHA-1 signature in a ServerKeyExchange
message it MUST abort the connection with the illegal_parameter
alert.
Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages.
If a server receives a CertificateVerify message with MD5 or SHA-1 it
MUST abort the connection with handshake_failure or
insufficient_security alert.
Draft: draft-ietf-tls-md5-sha1-deprecate-00

Commentary: replying with handshakefailure when server breaks protocol invariants is n't a good idea , make the behaviour conditional on values in signaturealgorithms ( since this is the normal behaviour a client should exhibit when a signature algorithm is disabled , this does not actually increase complexity of the implementation )
Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange message.
If client does receive a MD5 or SHA-1 signature in the
ServerKeyExchange message it MUST abort the connection with
handshake_failure or insufficient_security alert.
Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange message.
If client does receive a MD5 or SHA-1 signature in the
ServerKeyExchange message and it sent one in signature_algorithms
extensions it MUST abort the connection with handshake_failure or
insufficient_security alert.  If client did not send MD5 nor SHA-1
hash algorithm in signature_algorithms extension and it receives a
MD5 or SHA-1 signature in the ServerKeyExchange it MUST abort the
connection with the illegal_parameter alert.
Draft: draft-ietf-tls-md5-sha1-deprecate-00

Commentary: SHA-1 is spelled everywhere as " SHA-1 " , it 's the only instance of " SHA1 " change it so that it is consistent
such as way that MD5 and SHA1 MUST NOT be used for digital
signatures.  However, this document does not deprecate SHA-1 in HMAC
for record protection.
such as way that MD5 and SHA-1 MUST NOT be used for digital
signatures.  However, this document does not deprecate SHA-1 in HMAC
for record protection.