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

Commentary: LGTM . can you accept suggestion ? I ca n't do that myself as the branch is on a separate repo . Then it 's ready to merge I think .
While the Certificate message in TLS 1.3 is encrypted, third parties
can draw inferences from the message length observed on the wire.
TLS 1.3 provides a padding mechanism (discussed in Sections 5.4 and
E.3 of RFC8446) to counteract such analysis.  Certificate compression
alters the length of the Certificate message, and the change in
length is dependent on the actual contents of the certificate.  Any
padding scheme covering the Certificate message has to address
compression within its design, or disable it altogether.
Draft: draft-ietf-tls-certificate-compression

Commentary: Update reference .
If the specified compression algorithm is zlib, then the Certificate
message MUST be compressed with the ZLIB compression algorithm, as
defined in RFC1950.  If the specified compression algorithm is
brotli, the Certificate message MUST be compressed with the Brotli
compression algorithm as defined in RFC7932.  If the specified
compression algorithm is zstd, the Certificate message MUST be
compressed with the Zstandard compression algorithm as defined in
RFC8478.
If the specified compression algorithm is zlib, then the Certificate
message MUST be compressed with the ZLIB compression algorithm, as
defined in RFC1950.  If the specified compression algorithm is
brotli, the Certificate message MUST be compressed with the Brotli
compression algorithm as defined in RFC7932.  If the specified
compression algorithm is zstd, the Certificate message MUST be
compressed with the Zstandard compression algorithm as defined in I-
D.kucherawy-rfc8478bis.
Draft: draft-ietf-tls-certificate-compression

Commentary: Parking this here ; if we have a consensus on the list to add it , we should merge this .
If the specified compression algorithm is zlib, then the Certificate
message MUST be compressed with the ZLIB compression algorithm, as
defined in RFC1950.  If the specified compression algorithm is
brotli, the Certificate message MUST be compressed with the Brotli
compression algorithm as defined in RFC7932.
If the specified compression algorithm is zlib, then the Certificate
message MUST be compressed with the ZLIB compression algorithm, as
defined in RFC1950.  If the specified compression algorithm is
brotli, the Certificate message MUST be compressed with the Brotli
compression algorithm as defined in RFC7932.  If the specified
compression algorithm is zstd, the Certificate message MUST be
compressed with the Zstandard compression algorithm as defined in
RFC8478.
Draft: draft-ietf-tls-certificate-compression

Commentary: State explicitly that we do not define any compression dictionaries . Explain the rationale behind the uncompressed_length field . Addresses comments from   on the list . 
 Actually , I have a small nit .
The length of the Certificate message once it is uncompressed.  If
after decompression the specified length does not match the actual
length, the party receiving the invalid message MUST abort the
connection with the "bad_certificate" alert.
The length of the Certificate message once it is uncompressed.  If
after decompression the specified length does not match the actual
length, the party receiving the invalid message MUST abort the
connection with the "bad_certificate" alert.  The presence of this
field allows the receiver to pre-allocate the buffer for the
uncompressed Certificate message and to enforce limits on the
message size before performing decompression.
It is possible to define a certificate compression algorithm that
uses a pre-shared dictionary to achieve higher compression ratio.
This document does not define any such algorithms.
Draft: draft-ietf-tls-certificate-compression

Commentary: Thanks for doing this I ended up being tied up in a bunch of other stuff . 
 See message on mailing list from for more details : 
 Do we actually have consensus for this requiring a mitigation ? 
 I probably worded the title wrong . I created this just to keep track of the issue . 
 lgtm
In order for certificate compression to function correctly, the
underlying compression algorithm MUST be deterministic and it MUST
output the same data that was provided as input by the peer.
Draft: draft-ietf-tls-certificate-compression

Commentary: Now that TLS and DTLS are in the RFC editor 's list of abbreviations as " common " there 's no need to spell out Transport Layer Security anymore .
In Transport Layer Security (TLS) handshakes, certificate chains
often take up the majority of the bytes transmitted.
In TLS handshakes, certificate chains often take up the majority of
the bytes transmitted.
In order to reduce latency and improve performance it can be useful
to reduce the amount of data exchanged during a Transport Layer
Security (TLS) handshake.
In order to reduce latency and improve performance it can be useful
to reduce the amount of data exchanged during a TLS handshake.
Draft: draft-ietf-tls-certificate-compression

Commentary: In preparation of the IANA TLS update RFC publication .
Create an entry, compress_certificate(27), in the existing registry
for ExtensionType (defined in I-D.ietf-tls-tls13), with "TLS 1.3"
column values being set to "CH, CR".
Create an entry, compress_certificate(27), in the existing registry
for ExtensionType (defined in I-D.ietf-tls-tls13), with "TLS 1.3"
column values being set to "CH, CR", and "Recommended" column being
set to "Yes".
Draft: draft-ietf-tls-certificate-compression

Commentary: It 's been pointed out that one byte may not be sufficient to run experimental compression algorithms without collisions . Expand the space to 2 ^ 16 values , and update the IANA considerations section accordingly . 
 suggested expanding the compression code point from 1 byte to 2 . 
 Do we really want to do that ? I can write up a PR , but I do n't really see us ever having more than 20 of those ... Old compression types took up only one byte ; I expect us to have more , because dictionaries , but not much more , because realistically there are only so many codepoints we can deploy . 
 Since it was mentioned at the meeting I thought I create an issue so it can be discussed . I 'm fine closing since I agree we probably do n't need this , unless or someone else has a reason for doing this ( and we can reopen later if needed ) . 
 I suggested expanding this due to the potential future use of dictionaries . I agree we will likely never have more than 20 standardized code points , but 1 byte is a bit low for experimental use without worry of collision . 1 byte is probably enough , but 2 bytes would definitely be enough , and the cost of 1 extra byte seems pretty low to me . 
 Fixed in . 
 Added comment , otherwise lgtm .
The values in this registry shall be allocated under "IETF Review"
policy for values strictly smaller than 64, under "Specification
Required" policy for values 64-223, and under "Private Use" otherwise
(see RFC8126 for the definition of relevant policies).
The values in this registry shall be allocated under "IETF Review"
policy for values strictly smaller than 256, under "Specification
Required" policy for values 256-16383, and under "Experimental Use"
otherwise (see RFC8126 for the definition of relevant policies).
Experimental Use extensions can be used both on private networks and
over the open Internet.
Draft: draft-ietf-tls-certificate-compression

Commentary: This fixes some of the comments from and more .
The words "MUST", "MUST NOT", "SHALL", "SHOULD", and "MAY" are used
in this document.  It's not shouting; when they are capitalized, they
have the special meaning defined in RFC2119.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.
If the format of the Certificate message is altered using the
server_certificate_type extension RFC7250, the resulting altered
message is compressed instead.
If the format of the Certificate message is altered using the
server_certificate_type or client_certificate_type extensions
RFC7250, the resulting altered message is compressed instead.
The values in this registry shall be allocated under "IETF Review"
policy for values strictly smaller than 64, under "Specification
Required" policy for values 64-223, and under "Private Use" otherwise
(see RFC8126 for the definition of relevant policies).
Draft: draft-ietf-tls-certificate-compression

Commentary: We already had the understanding that no one will attempt to deploy the extension for TLS 1.2 and earlier , since it would be plagued with middlebox compatibility issues that TLS 1.3 already faces . However , it was left as supported because there was no cost to supporting it . On the list ,   has pointed out that : clients have no way to ask for " compress only in TLS 1.3 " policy , meaning that they have to assume that a TLS 1.2 connection could attempt to use this extension ; clients have to support certificate compression in TLS 1.2 as a result . This adds complexity for no reason , and the problem is easily solved by restricting the extension to 1.3 or higher . 
 : +1 : LGTM
This document defines a new extension type
(compress_certificate(TBD)), which can be used to signal the
supported compression formats for the Certificate message to the
peer.  Whenever it is sent by the client as a ClientHello message
extension (RFC5246, Section 7.4.1.4), it indicates the support for
compressed server certificates.  Whenever it is sent by the server as
a CertificateRequest extension (I-D.ietf-tls-tls13, Section 4.3.2),
it indicates the support for compressed client certificates.  Note
that CertificateRequest messages are not supported by TLS versions
prior to 1.3.
This extension is only supported with TLS 1.3 and newer; if TLS 1.2
or earlier is negotiated, the peers MUST ignore this extension.
This document defines a new extension type
(compress_certificate(TBD)), which can be used to signal the
supported compression formats for the Certificate message to the
peer.  Whenever it is sent by the client as a ClientHello message
extension (I-D.ietf-tls-tls13, Section 4.1.2), it indicates the
support for compressed server certificates.  Whenever it is sent by
the server as a CertificateRequest extension (I-D.ietf-tls-tls13,
Section 4.3.2), it indicates the support for compressed client
certificates.
It's been observed that a significant number of middleboxes intercept
and try to validate the Certificate message exchanged during a TLS
handshake.  This means that middleboxes that don't understand the
CompressedCertificate message might misbehave and drop connections
that adopt certificate compression.
However this is not a problem when using TLS version 1.3 I-D.ietf-
tls-tls13 and higher, due to the fact that the Certificate (and thus
the CompressedCertificate) message is encrypted, preventing
middleboxes from intercepting it.
It's been observed that a significant number of middleboxes intercept
and try to validate the Certificate message exchanged during a TLS
handshake.  This means that middleboxes that don't understand the
CompressedCertificate message might misbehave and drop connections
that adopt certificate compression.  Because of that, the extension
is only supported in the versions of TLS where the certificate
message is encrypted in a way that prevents middleboxes from
intercepting it, that is, TLS version 1.3 I-D.ietf-tls-tls13 and
higher.
Draft: draft-ietf-tls-certificate-compression

Commentary: I feel like we should provide a somewhat more specific guidance . " Server implementations MAY choose to negotiate certificate compression only in cases when the TLS version is 1.3 or newer " ? ( SHOULD is also fine , we should probably pick whatever level draft22 compat hacks use ) 
 AFAICT draft22 does n't use any specific RFC2119 words for the compat mode ( it just says " can use " a bunch of times ) . Also , I think this is somewhat different in that there 's no real change between TLSv1.2 and TLSv1.3 for compression ( differently from the TLSv1.3 compat mode where the protocol actually slightly changes ) . So , knowing the risk , it should just be up to the server and the client to decide whether to use compression or not with TLS < 1.3 IMO . 
 Good point .
It's been observed that a significant number of middleboxes intercept
and try to validate the Certificate message exchanged during a TLS
handshake.  This means that middleboxes that don't understand the
CompressedCertificate message might misbehave and drop connections
that adopt certificate compression.
However this is not a problem when using TLS version 1.3 [draft-ietf-
tls-tls13] and higher, due to the fact that the Certificate (and thus
the CompressedCertificate) message is encrypted, preventing
middleboxes from intercepting it.