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

Commentary: For the ctls_template message type it is OK to set the DTLS - OK field to " Y " . The entire message is not applicable to regular TLS / DTLS and hence there is no harm whatever value is in the IANA registry . 
 I still think it 's unclear what this means , but I agree that it does n't matter much and " Y " is ... not wrong .
DTLS-OK: ??? Not clear what to put here.
Draft: draft-ietf-tls-ctls

Commentary: Removed this sentence : The current draft already offers an allocation policy .
OPEN ISSUE: Should we require standards action for all profile IDs
that would fit in 2 octets.
Draft: draft-ietf-tls-ctls

Commentary: The example did not account for the record layer , and seemed to overlook some other details as well . 
 CTLSClientPlaintext and CTLSServerPlaintext seem to be included in the example exchange but CTLSCiphertext seems to be missing . My understanding is that ServerFlight and ClientFlight are sent over CTLSCiphertext which would add a mimimum of 2 * 11 bytes . It is not explained why the signature is 64 bytes . In TLS 1.3 , my understanding is that ecdsasecp256r1sha256 is variable length 12 - 76 bytes with an average length close to 75 bytes . Changing ecdsasecp256r1sha256 to ( or ecdsasecp256r1sha256_compact ) would make it 64 bytes . The introduction promises an example PSK handshake , but that is missing . 
 Please review , which attempts to fix the example as you 've described .
For the common (EC)DHE handshake with pre-established certificates,
Stream cTLS achieves an overhead of 45 bytes over the minimum
required by the cryptovariables.  For a PSK handshake, the overhead
is 21 bytes.  Annotated handshake transcripts for these cases can be
found in transcripts.
TODO: Update these values.
For the common (EC)DHE handshake with pre-established certificates,
Stream cTLS achieves an overhead of 53 bytes over the minimum
required by the cryptovariables.  For a PSK handshake, the overhead
is 21 bytes.  An annotated handshake transcript can be found in
transcripts.
TODO: Make a PSK transcript and check the overhead.
TODO: It seems like there was an intent to elide the
"Certificate.certificate_request_context" field, but this is not
stated explicitly anywhere.
Draft: draft-ietf-tls-ctls

Commentary: Note that this change is blocked by the CI due to trailing whitespace .
This document specifies a "compact" version of TLS and DTLS.  It is
logically isomorphic to ordinary TLS, but saves space by trimming
obsolete material, tighter encoding, a template-based specialization
technique, and alternative cryptographic techniques. cTLS is not
directly interoperable with TLS or DTLS, but it should eventually be
possible for a single server port to offer cTLS alongside TLS or
DTLS.
This document specifies a "compact" version of TLS 1.3 and DTLS 1.3.
It is logically isomorphic to ordinary TLS, but saves space by
trimming obsolete material, tighter encoding, a template-based
specialization technique, and alternative cryptographic techniques.
cTLS is not directly interoperable with TLS 1.3 or DTLS 1.3 since the
over-the-wire framing is different.  A single server can, however,
offer cTLS alongside TLS or DTLS.
Draft: draft-ietf-tls-ctls

Commentary: We have decided to moved the compressed elliptic curve representations to an external draft since the issue is equally applicable to regular TLS / DTLS and does not need to be cTLS specific . 
 It looks like you need to run . 
 It seems that we have consensus to move compressed representations into new IANA codepoints , rather than try to reuse the existing codepoints with a template - driven encoding . That would make the question of compressed representations orthogonal to cTLS , so this topic can be removed from the draft . 
 Fixed by
More compact encodings, for example point compression.
Alternative cryptographic techniques, such as semi-static Diffie-
Hellman.
OPEN ISSUE: Semi-static and point compression are never mentioned
again.
More compact encodings.
Alternative cryptographic techniques, such as nonce truncation.
Draft: draft-ietf-tls-ctls

Commentary: In the case a cTLS handshake uses a self - delimiting extension ( in additional extensions ) that is not present in section 4.2 of RFC 8446 , its length is always serialized . With this PR , the type of this extension can be stored in and its length can be omitted .
The "self_delimiting_extensions" field indicates extensions whose
data is self-delimiting.  The cTLS implementation MUST be able to
parse all these extensions, and all extensions listed in Section 4.2
of RFC8446.
"Extension.extension_data" for any extension in
"expected_extensions" whose value is self-delimiting (e.g., fixed
length).  This applies only to the corresponding message.
"Extension.extension_data" for any extension whose type is in
"self_delimiting_extensions", or is listed in Section 4.2 of
RFC8446 except "padding".  This applies only to the corresponding
message.
"selfDelimitingExtensions": an array of "ExtensionType" names.
In addition to the static vectors implied by various template
elements, "Extension.extension_data" is always static in cTLS if the
extension is any type listed in Section 4.2 of RFC8446 except
"padding".  cTLS implementations MUST be able to parse any of these
extensions that the other party is permitted to send, but no other
support is required.
Draft: draft-ietf-tls-ctls

Commentary: LGTM . 
 Is it a design goal of this draft to support secure connection , even if the compression template is distributed over an untrusted channel ? I believe it is a design goal , and I think it 's probably achieved by the current draft ( except for questions around the and keys ) , but it 's not stated explicitly in the draft .
OPEN ISSUE: How short should we allow this to be?  TLS 1.3 uses
the native hash and TLS 1.2 used 12 bytes.  More analysis is
needed to know the minimum safe Finished size.  See RFC8446,
Section E.1 for more on this, as well as
https://mailarchive.ietf.org/arch/msg/tls/
TugB5ddJu3nYg7chcyeIyUqWSbA.
OPEN ISSUE: How short should we allow this to be?  TLS 1.3 uses
the native hash and TLS 1.2 used 12 bytes.  More analysis is
needed to know the minimum safe Finished size.  See RFC8446,
Section E.1 for more on this, as well as
https://mailarchive.ietf.org/arch/msg/tls/
TugB5ddJu3nYg7chcyeIyUqWSbA.  The minimum safe size may vary
depending on whether the template was learned via a trusted
channel.
Transcript expansion also needs some analysis and we need to
determine whether we need an extension to indicate that cTLS is in
use and with which profile.
Once the handshake has completed, this specification is intended to
provide a fully secured connection even if the client initially
learned the template through an untrusted channel.  However, this
security relies on the use of a cryptographically strong Finished
message.  If the Finished message has not yet been received, or the
transcript hash has been truncated by use of a small "finished_size"
template element value, an attacker could be using a forged template
to impersonate the other party.  This should not impact any ordinary
use of TLS, including Early Data (which is secured by the previously
completed handshake).
Draft: draft-ietf-tls-ctls

Commentary: Empty messages must now be included . If the body is known to be empty from the template , this costs one byte . This change also adjusts the explanation of and , and corrects the example . 
 points out that EndOfEarlyData is an empty message that is semantically meaningful and can not be predicted by the recipient .
This is equivalent to a literal "signature_algorithms" extension
consisting solely of this group.
This is equivalent to a placing a literal "signature_algorithms"
extension consisting solely of this group in every extensions field
where it is permitted to appear.
If set to true, this element indicates that the client must
authenticate with a certificate by sending Certificate and a
CertificateVerify message.  The server MUST omit the
CertificateRequest message, as its contents are redundant.
OPEN ISSUE: We don't actually say that you can omit empty
messages, so we need to add that somewhere.
If set to true, this element indicates that the client must
authenticate with a certificate by sending Certificate and a
CertificateVerify message.  If the CertificateRequest message does
not add information not already conveyed in the template, the server
SHOULD omit it.
Draft: draft-ietf-tls-ctls

Commentary: This change also reserves short profile IDs for " well - known " use . Fixes 
 Can we please try to resolve this question soon to unblock implementation ? 
 Any objection to merging this ? 
 The template says it 's an integer ( in what range ? ) , but the ClientHello says it 's 0 - 255 bytes . I think it 's probably easiest to say it 's a string of 0 - 255 bytes , with the empty string reserved to mean " no template " . I guess if you want to get fancy you could reserve all 1 - 4 byte strings . 
 Agreed . If you want to send a PR , I would n't object . 
 This LGTM .
identifies the profile being defined.
identifies the profile being defined (default: "").  If present,
this key MUST contain a hex-encoded sequence of 0-255 bytes (the
"profile ID").  IDs whose decoded length is 4 bytes or less are
reserved (see reserved-profiles).  When a reserved value is used
(including the default value), other keys MUST NOT appear in the
template, and a client MUST NOT accept the template unless it
recognizes the ID.
OPEN ISSUE: The profile_id is needed in the ClientHello to inform
the server what compression profile to use.  For a ServerHello
this field is not required.  Should we make this field optional?
The client uses the "profile_id" field to inform the server about the
compression profile being used (see template-based-specialization).
This field MUST be set to a zero-length value and only if no
compression profile is used.  Non zero-length values are agreed out
of band between the client and server, as part of the specification
of the compression profile.
The "profile_id" field MUST identify the profile that is in use.  A
zero-length ID corresponds to the cTLS default protocol.
OPEN ISSUE: Should we have a registry of well-known profiles?
ID value: A sequence of 1-4 octets.
Template: A JSON object.
Note: An explanation or reference.
The ID values of length 1 are subject to a "Standards Action"
registry policy.  Values of length 2 are subject to an "RFC Required"
policy.  Values of length 3 and 4 are subject to a "First Come First
Served" policy.  Values longer than 4 octets are not subject to
registration and MUST NOT appear in this registry.
Draft: draft-ietf-tls-ctls

Commentary: I 'm slightly concerned about the fact that we have two different wire behaviors with the same transcript , but because the integrity tag includes the header , I think it 's OK . would welcome your thoughts . 
 I think I have addressed this aspect already in PR 
 Correct . I thought  's suggestion to tie it to transport made more sense , but I 'm not hard over on it . 
 Fine for me too . 
 S = " sequence number "
Normal DTLS does not provide a mechanism for suppressing the sequence
number field entirely.  In cases where a sequence number is not
required (e.g., when a reliable transport is in use), a cTLS
implementation may suppress it by setting the
"suppressSequenceNumber" flag in the compression profile being used
(see template-based-specialization).  When this flag is enabled, the
S bit in the configuration octet MUST be cleared.
Normal DTLS does not provide a mechanism for suppressing the sequence
number field entirely.  When a reliable, ordered transport (e.g.,
TCP) is in use, the S bit in the configuration octet MUST be cleared
and the sequence number MUST be omitted.  When an unreliable
transport is in use, the S bit has its usual meaning and the sequence
number MUST be included.
Draft: draft-ietf-tls-ctls

Commentary: I wonder whether this works . Here is the solution I came up with 
 yeah that seems more complicated . Is there a reason why this wo n't work ? 
 IMHO we somehow have to distinguish between three types of message ( via the content type ): plaintext handshake messages ( for the ClientHello , ServerHello / HRR ) encrypted cTLS messages , and plaintext alert messages Do I see this wrong ? 
 Agreed . But that 's plaintext handshake messages ( for the ClientHello , ServerHello / HRR ) --ctls_handshake encrypted cTLS messages , and --The ordinary DTLS rules plaintext alert messages --tls alert . 
 I guess I was thinking about this in a too complicated way . Do you want to use the regular TLS Alert message format ? ( Fine for me . ) 
 That is my proposal . 
 I think the logical way to do this would be to register in the . Otherwise , you 're setting up a potential collision as more values are to that registry . 
 Yes , I agree with that . I 'm just talking about the technical approach 
 OK , then I think this PR might as well add the IANA instruction for that . 
 I made a separate IANA PR 
 It ’s currently not clear how plaintext Alerts are represented . Suggestion : contenttype = ctlsalert 
 I created a PR to address this issue : 
 why ca n't they just be the usual content type ? What am I missing . 
 The current text says records ( ClientHello and ServerHello / HRR ) . The content type is therefore constant ( it is always handshake ) , so we instead set the contenttype field to a fixed cTLS - specific value to distinguish cTLS plaintext records from encrypted records , TLS / DTLS records , and other protocols using the same 5 - tuple . I 'm proposing that : first sentence ( or maybe the second ) is not right . need another for plaintext alerts . I 'm not sure what you mean by " the usual content type " . cTLS currently does not use TLS 's ContentType registry . Instead , the current draft defines a new value to identify these records . If you 're proposing to switch cTLS to use the TLS ContentTypes instead ... that seems fine to me . However , the divergence does seem to be deliberate , as explained in the text . 
 I think this is just an error on my part : obviously need to be able to send plaintext alerts . requirement is to be able to demux , but if cTLS alerts are the same , then no need For that reason , I propose to just use TLS 's alert type .
The only cTLS records that are sent in plaintext are handshake
records (ClientHello and ServerHello/HRR).  The content type is
therefore constant (it is always "handshake"), so we instead set the
"content_type" field to a fixed cTLS-specific value to distinguish
cTLS plaintext records from encrypted records, TLS/DTLS records, and
other protocols using the same 5-tuple.
The only cTLS records that are sent in plaintext are handshake
records (ClientHello and ServerHello/HRR) and alerts. cTLS alerts are
the same as TLS alerts and use the same content types.  For handshake
records, we set the "content_type" field to a fixed cTLS-specific
value to distinguish cTLS plaintext records from encrypted records,
TLS/DTLS records, and other protocols using the same 5-tuple.
Draft: draft-ietf-tls-ctls

Commentary: For cTLS / TCP , the CTLSCiphertext headers could easily all be the same size ( 1 byte type / flags , 2 byte length ) . For cTLS / UDP , the header sizes could be made more predictable . Suggestions : Always suppress sequence numbers and disallow connection IDs in cTLS / TCP , and after the first record in a datagram in cTLS / UDP . Move into the cTLS ClientHello struct . 
 Moving the profile_id into the ClientHello sounds good to me . Here is the PR : 
 Suppressing sequence numbers in cTLS / TCP sounds good to me as well . Here is the PR : 
 closing as I think we addressed .
The "profile_id" field allows the client and server to agree on which
compression profile should be used for this session (see template-
based-specialization).  This field MUST be set to zero if and only if
no compression profile is used.  Non-zero values are negotiated out
of band between the client and server, as part of the specification
of the compression profile.
The client uses the "profile_id" field to inform the server about the
compression profile being used (see template-based-specialization).
This field MUST be set to a zero-length value and only if no
compression profile is used.  Non zero-length values are agreed out
of band between the client and server, as part of the specification
of the compression profile.
Draft: draft-ietf-tls-ctls

Commentary: This PR looks good to me . 
 cTLS enumerates keys in the template , but does not explain how templates can be extended . Suggestion : Clients must reject the whole template if it contains any key they do not understand . The “ optional ” key holds a map of optional extensions that are safe to ignore . 
 Thanks for addressing your own issue with a PR . Creating an IANA registry for the keys used in the configuration data makes sense . I would , however , like to point out ( and maybe we need to make this explicit ) that the configuration information is defined for convenience but is not a mandatory - to - implement functionality for a stack . 
 Sure , some use cases can pre - arrange , or even hardcode , a specific configuration through a nonstandard channel . Some use cases ( where the client and server are developed separately ) obviously can not .
contains keys that are not required to be understood by the
client.  Server operators MUST NOT place a key in this section
unless the server is able to determine whether the key is in use
based on the client data it receives.  A key MUST NOT appear in
both the main template and the optional section.
Draft: draft-ietf-tls-ctls

Commentary: Remove redundant file 
 this is the clarification I intended .
indicates whether the client has to be prepared to transmit a
Certificate and a CertificateVerify message and whether the server
has to transmit a CertificateRequest message.
Draft: draft-rescorla-tls-ctls

Commentary: Made sequence numbers optional
Encrypted records use the DTLS 1.3 record framing, including optional
connection IDs.
As with DTLS, the length field MAY be omitted by clearing the L bit,
which means that the record consumes the entire rest of the data in
the lower level transport.  In this case it is not possible to have
multiple DTLSCiphertext format records without length fields in the
same datagram.  In stream-oriented transports (e.g., TCP), the length
field MUST be present.
Encrypted records use an optimized version of the DTLS 1.3 record
framing, including optional CIDs and optional sequence numbers.Unlike
the CID and the Length field, the sequence number field in the record
layer header is context dependent and the present or absence is not
indicated via a bit flag.  Sequence numbers are not used when the
payloads are carried over reliable transports.
As with DTLS, the length field MAY be omitted by clearing the L bit,
which means that the record consumes the entire rest of the data in
the lower level transport.  In this case it is not possible to have
multiple DTLSCiphertext format records without length fields in the
same datagram.  In stream-oriented transports (e.g., TCP), the length
field MUST be present.  For use over other transports length
information may be inferred from the underlying layer.
Draft: draft-ietf-tls-ctls

Commentary: Suggested expansion on the intro :
We do not show the structures which only change in this way.
This allows implementations' encoding and decoding logic to implement
cTLS simply by having a mode in which integers always use the varint
encoding.  Note that if implementations treat opaque data in the same
way as "uint8" values, they MUST NOT convert the bytes of an opaque
value to varints.
Values of type uint8, opaque values, and one-byte enums are not
affected.  We do not show the structures which only change in this
way.
Draft: draft-rescorla-tls-ctls

Commentary: I noticed a few minor typos while reading the draft .
A template-based specialization mechanism that allows for the
creation of application specific versions of TLS that omit
unnecessary valuses.
For the common (EC)DHE handshake with pre-established certificates,
cTLS achieves an overhead of 45 bytes over the minimum required by
the cryptovariables.  For a PSK handshake, the overhead is 21 bytes.
Annotated handsdhake transcripts for these cases can be found in
transcripts.
A template-based specialization mechanism that allows for the
creation of application specific versions of TLS that omit
unnecessary values.
For the common (EC)DHE handshake with pre-established certificates,
cTLS achieves an overhead of 45 bytes over the minimum required by
the cryptovariables.  For a PSK handshake, the overhead is 21 bytes.
Annotated handshake transcripts for these cases can be found in
transcripts.
We can slim down the Certficate message somewhat.
We can slim down the Certificate message somewhat.
Draft: draft-rescorla-tls-ctls

Commentary: Something went wrong with this PR . It is removing the tables that put in
Omitting the fields and handshake messages required for preserving
backwards-compatibility with earlier TLS versions.
indicates that both sides agree to the single TLS version
specified by the given integer value (772 == 0x0304 for TLS 1.3).
The ClientHello.versions field field is omitted and reconstructed
in the transcript as a single-valued list with the specified
value.  The ServerHello.version field is omitted and reconstructed
in the transcript as the specified value.
indicates that both sides agree to the single TLS version
specified by the given integer value (772 == 0x0304 for TLS 1.3).
The ClientHello.versions field is omitted and reconstructed in the
transcript as a single-valued list with the specified value.  The
ServerHello.version field is omitted and reconstructed in the
transcript as the specified value.
Version 772 corresponds to the hex representation 0x0304, named group
"29" (0x001D) represents X25519.
Draft: draft-rescorla-tls-ctls

Commentary: CBOR is a too complex route IMHO
The mapping for TLS 1.3 ciphersuites to their 1 byte equivalent is
defined as the low-order byte of the existing TLS 1.3 IANA
ciphersuite registry values.