jiebi/CodeConvo huggingface dataset:
Change:
This revises the description of SRTP and the relation between SRTP, DTLS, and ZRTP.
If we keep that headline, we need one for DTLS-SRTP too. Yes, that was intentional. SRTP is just the record protocol. The key management is usually done by DTLS or occasionally by ZRTP.
Comment from Ekr's review of -10: Pre-Connection Interfaces […] Also, I'm not sure you want to omit tcpcrypt here, in that it does have a way to do external authentication by exporting a session ID. Also ZRTP allows for some sort of fingerprint-based auth. tcpcrypt (and I believe ZRTP) both have session caches.
ZRTP uses , compared by the users, as an external authentication mechanism (similar process to the Safety Numbers in Signal, I believe). ZRTP does maintain a session cache.
In other words, ZRTP supports interfaces to Authentication Delegation and Session Cache Management, and DTLS-SRTP does not?
Thanks for the reply. I'm okay with merging these changes as they are, or you can add that one reference for ZRTP to have both.

Discussion:
Secure RTP (SRTP) is a profile for RTP that provides confidentiality, message authentication, and replay protection for RTP data packets <del> and RTP control protocol (RTCP) packets RFC3711.  SRTP can use different handshake protocols, such as DTLS in DTLS-SRTP RFC5764 or ZRTP RFC6189. </del> <ins> and RTP control protocol (RTCP) packets RFC3711.  SRTP provides a record layer only, and requires a separate handshake protocol to provide key agreement and identity management. </ins> <del> 3.2.2. </del> <ins> The commonly used handshake protocol for SRTP is DTLS, in the form of DTLS-SRTP RFC5764.  This is an extension to DTLS that negotiates the use of SRTP as the record layer, and describes how to export keys for use with SRTP. </ins> <del> ZRTP RFC6189 is an alternative key agreement protocol for SRTP.  It uses standard SRTP to protect RTP data packets and RTCP packets, but provides alternative key agreement and identity management protocols. Key agreement is performed using a Diffie-Hellman key exchange that runs on the media path.  This generates a shared secret that is then used to generate the master key and salt for SRTP. </del> <ins> ZRTP RFC6189 is an alternative key agreement and identity management protocols for SRTP.  ZRTP Key agreement is performed using a Diffie- Hellman key exchange that runs on the media path.  This generates a shared secret that is then used to generate the master key and salt for SRTP. </ins> 3.3.

DTLS <del> SRTP </del> ZRTP <ins> SRTP </ins> Transport-Layer Security Protocols: QUIC

Application Payload Security Protocols: <ins> DTLS when used as a handshake protocol for SRTP ZRTP </ins> SRTP Packet Security Protocols:

separate module that will provide authentication, using EAP for example. <del> SRTP </del> IKEv2 tcpcrypt

DTLS <del> SRTP </del> <ins> ZRTP </ins> QUIC
Change:
Address
URL Hi, I concur. However, I'd suggest changing the title of the section from "IKEv2 with ESP" to "IPsec". Regards, Valery.

Discussion:
identifying the interfaces between these protocols and both transport protocols and applications.  It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google <del> QUIC (gQUIC), tcpcrypt, Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimaLT.  For each protocol, this document provides a brief description.  Then, it describes the interfaces between these protocols and transports in transport-interface and the interfaces between these protocols and applications in application-interface. </del> <ins> QUIC (gQUIC), tcpcrypt, Internet Protocol Security (IPsec), SRTP (with DTLS), WireGuard, CurveCP, and MinimaLT.  For each protocol, this document provides a brief description.  Then, it describes the interfaces between these protocols and transports in transport- interface and the interfaces between these protocols and applications in application-interface. </ins> Selected protocols represent a superset of functionality and features a Transport Services system may need to support, both internally and

Packet Security Protocols: <del> IKEv2 and ESP </del> <ins> IPsec </ins> WireGuard

Packet Security Protocols: <del> IKEv2 and ESP </del> <ins> IPsec </ins> 4.3.

a separate module that will provide authentication, using EAP for example. <del> IKEv2 </del> <ins> IPsec </ins> tcpcrypt

ESP <del> IKEv2 </del> <ins> IPsec </ins> OpenVPN

QUIC <del> IKEv2 </del> <ins> IPsec </ins> WireGuard

MinimaLT <del> IKEv2 </del> <ins> IPsec </ins> OpenVPN

MinimaLT <del> IKEv2 </del> <ins> IPsec </ins> Shared Secret Export (PSKE): The handshake protocol may provide an interface for producing shared secrets for application-specific

tcpcrypt <del> IKEv2 </del> <ins> IPsec </ins> OpenVPN

CurveCP <del> IKEv2 </del> <ins> IPsec </ins> WireGuard
Change:
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: URL
Suppressing sequence numbers in cTLS/TCP sounds good to me as well. Here is the PR: URL
NAME closing as I think we addressed.

Discussion:
cTLS plaintext records from encrypted records, TLS/DTLS records, and other protocols using the same 5-tuple. <del> 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. </del> [[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 cTLS ClientHello is defined as follows. <ins> 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. </ins> 3.2. We redefine ServerHello in the following way.
Change:
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. NAME would welcome your thoughts.
I think I have addressed this aspect already in PR URL
Correct. I thought Ben'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"

Discussion:
information may be inferred from the underlying layer. Normal DTLS does not provide a mechanism for suppressing the sequence <del> 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. </del> <ins> 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. </ins> 2.3.
Change:
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.
NAME points out that EndOfEarlyData is an empty message that is semantically meaningful and cannot be predicted by the recipient.

Discussion:
Value: a single "SignatureScheme" (RFC8446, Section 4.2.3) to use for authentication. <del> This is equivalent to a literal "signature_algorithms" extension consisting solely of this group. </del> <ins> 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. </ins> In JSON, the signature algorithm is listed by the code point name in RFC8446, Section 4.2.3. (e.g., ecdsa_secp256r1_sha256).

If set to true, this element indicates that the client must authenticate with a certificate by sending Certificate and a <del> 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. </del> <ins> CertificateVerify message.  If the CertificateRequest message does not add information not already conveyed in the template, the server SHOULD omit it. </ins> In JSON, this value is represented as "true" or "false".
Change:
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.

Discussion:
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/ <del> TugB5ddJu3nYg7chcyeIyUqWSbA. </del> <ins> TugB5ddJu3nYg7chcyeIyUqWSbA.  The minimum safe size may vary depending on whether the template was learned via a trusted channel. </ins> In JSON, this length is represented as an integer.

source of identity misbinding.  This is, however, entirely separable from the rest of the specification. <del> 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. </del> <ins> 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). </ins> 6.
Change:
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.

Discussion:
"extensions" field.  The types of these extensions are omitted when serializing the "extensions" field of the corresponding message. <ins> 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. </ins> The "allow_additional" field MUST be 0 (false) or 1 (true), indicating whether additional extensions are allowed here.

Static vectors (see static-vectors): <del> "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. </del> <ins> "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. </ins> The "extensions" field of the corresponding message, if "allow_additional" is false.

"expectedExtensions": an array of "ExtensionType" names. <ins> "selfDelimitingExtensions": an array of "ExtensionType" names. </ins> "allowAdditional": "true" or "false". If "predefinedExtensions" or "expectedExtensions" is empty, it MAY be

their definition.  When encoding a "static vector", its length prefix is omitted. <del> 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. </del> For example, suppose that the cTLS template is: Then, the following structure:
Change:
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 ed25519 (or ecdsasecp256r1sha256_compact) would make it 64 bytes. The introduction promises an example PSK handshake, but that is missing.
NAME Please review , which attempts to fix the example as you've described.

Discussion:
again. For the common (EC)DHE handshake with pre-established certificates, <del> Stream cTLS achieves an overhead of 45 bytes over the minimum </del> <ins> Stream cTLS achieves an overhead of 53 bytes over the minimum </ins> required by the cryptovariables.  For a PSK handshake, the overhead <del> is 21 bytes.  Annotated handshake transcripts for these cases can be found in transcripts. </del> <ins> is 21 bytes.  An annotated handshake transcript can be found in transcripts. </ins> <del> TODO: Update these values. </del> <ins> TODO: Make a PSK transcript and check the overhead. </ins> cTLS supports the functionality of TLS and DTLS 1.3, and is forward- compatible to future versions of TLS and DTLS.  cTLS itself is

In JSON, this value is represented as "true" or "false". <ins> TODO: It seems like there was an intent to elide the "Certificate.certificate_request_context" field, but this is not stated explicitly anywhere. </ins> 2.1.1.8. Value: a single "CTLSExtensionTemplate" struct:
Change:
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 doesn't matter much and "Y" is ... not wrong.

Discussion:
Description: ctls_template <del> DTLS-OK: ??? Not clear what to put here. </del> <ins> DTLS-OK: Y </ins> Reference: (This document)
Change:
There were two minor typos. This PR fixes them. While I was at it, I ran over it, most seemed fine.

Discussion:
This design is not forward secret because the server's ESNI key is static.  However, the window of exposure is bound by the key <del> lifetime.  It is RECOMMEMDED that servers rotate keys frequently. </del> <ins> lifetime.  It is RECOMMENDED that servers rotate keys frequently. </ins> 7.2.6.
Change:
You are mixing URL in. That would seem to be sufficient. From that you can generate the AEAD nonce and key as though this were record protection. We don't need another reason for people to complain about exposing the random number generator state to the network.
If servers choose to use the same ESNI and semi-static key, not generating and including a nonce could lead to nonce-reuse for 0-RTT data. We talked about just prohibiting this sort of key sharing for servers, though it's good to have a client-side defense against it.

Discussion:
The label associated with the SNI encryption key. <del> A cryptographically random 128-bit nonce </del> The cipher suite used to encrypt the SNI. The original ServerNameList from the "server_name" extension,

The SNI encryption key is computed from the DH shared secret Z as follows: <del> The EncryptedSNI.encrypted_sni value is then computed by: </del> <ins> The EncryptedSNI.encrypted_sni value is then computed using the usual TLS 1.3 AEAD: Note: future extensions may end up reusing the server's ESNIKeyShare for other purposes within the same message (e.g., encrypting other values).  Those usages MUST have their own HKDF labels to avoid reuse. </ins> <del> [[OPEN ISSUE: This is a strawman construction.  We do want a nonce to avoid situations where the server somehow reuses a key, but exactly how we mix it in is TBD.  Maybe in both places?]] </del> <ins> [[OPEN ISSUE: If in future you were to reuse these keys for 0-RTT priming, then you would have to worry about potentially expanding twice of Z_extracted.  We should think about how to harmonize these.]] </ins> This value is placed in an "encrypted_server_name" extension.
Change:
Addresses .
An adversary who observes the certificate fingerprint could confirm certificates previously fetched by a ESNI-compatible client.
Fixed in .

Discussion:
The client MAY either omit the "server_name" extension or provide an innocuous dummy one (this is required for technical conformance with <del> RFC7540; Section 9.2.) </del> <ins> RFC7540; Section 9.2.).  The client MUST NOT send a "cached_info" extension RFC7924 with a CachedObject entry whose CachedInformationType is "cert". </ins> If the server does not negotiate TLS 1.3 or above, then the client MUST abort the connection with an "unsupported_version" alert.  If
Change:
The draft currently states: I'm confused about what this means. From reading RFC 7838, I'm not sure the SNI and DNS names do not match when you're querying an alternate name. In particular, RFC 7838 states: Which means, if I understand it correctly, the client will send "URL" in the SNI when trying to query resources from it - the requirement is only that the certificate for "URL" also cover "URL".
Agreed. I'm parsing RFC 7838 the same way. I think we should drop this text.
The problem the text presents is real (though the resolution is arbitrary). no.. that's a misread. See section 2.3 of 7838 The alternate is essentially just a cname for the origin. If host b is an alternate for origin a, in order to use the alternate you look up the DNS a/aaaa of b, do a TCP connect to b, and then use sni=a and expect a certificate valid for a. (indeed the point of the SNI is to tell the server what certificate you expect to see) With esni you would continue to do all of those things, except of course sni=encrypted(a).. and the question becomes where do you find the key used for the encryption. Is it the ESNI DNS record of a (the origin) or b (the alternate host). That's the question the text is trying to resolve - it says to use a (the origin). I could make a case for either choice but I think the text needs to decide
NAME Would you mind suggesting some text with an example to clear this up?
NAME thanks for the clarification and pointer to s2.3 of 7838. After reading that I think the text in the ESNI draft looks fine. (I'd just add a pointer to s2.3 of 7838 instead of just 7838 to help prevent the confusion I had)

Discussion:
complete, perhaps by timing out. In cases where the domain of the A or AAAA records being resolved do <del> not match the SNI Server Name, such as when RFC7838 is being used, the SNI domain should be used for querying the ESNI record. </del> <ins> not match the SNI Server Name, such as when RFC7838 Section 2.3 is being used, the SNI domain should be used for querying the ESNI record. </ins> Servers operating in Split Mode SHOULD have DNS configured to return the same A (or AAAA) record for all ESNI-enabled servers they
Change:
The current text about anonymity sets for records is too restrictive. If I have 100000 names and 100 IPs and for all queries I randomly return four out of my 100 IPs chosen randomly, I still provide the same anonymity set but I violate the SHOULD. The proposed text
The document currently states: I think this is too restrictive. If I have 100000 names and 100 IPs and for all queries I randomly return four out of my 100 IPs chosen randomly, I still provide the same anonymity set but I violate the SHOULD. How about:
Agreed. At a minimum this should reference a set of A and AAAA records rather than "the record" (as many records across the A and AAAA rrsets is very common). I think NAME proposed text is fine.
NAME sgtm, do you plan to open a PR? I made URL but I think your wording is better.
Created
LGTM -- thanks!

Discussion:
therefore allow clients to detect and recover from this situation (see esni-resolution for more details). <del> Servers operating in Split Mode SHOULD have DNS configured to return the same A (or AAAA) record for all ESNI-enabled servers they service.  This yields an anonymity set of cardinality equal to the number of ESNI-enabled server domains supported by a given client- facing server.  Thus, even with SNI encryption, an attacker which can enumerate the set of ESNI-enabled domains supported by a client- facing server can guess the correct SNI with probability at least 1/ K, where K is the size of this ESNI-enabled server anonymity set. This probability may be increased via traffic analysis or other mechanisms. </del> <ins> Content providers operating in Split Mode SHOULD ensure that the A and AAAA records for ESNI-enabled server names do not allow identifying the server name from the IP address.  This can for example be achieved by always returning the same records for all ESNI-enabled names, or by having the function that picks addresses from a pool not depend on the server name.  This yields an anonymity set of cardinality equal to the number of ESNI-enabled server domains supported by a given client-facing server.  Thus, even with SNI encryption, an attacker which can enumerate the set of ESNI-enabled domains supported by a client-facing server can guess the correct SNI with probability at least 1/K, where K is the size of this ESNI- enabled server anonymity set.  This probability may be increased via traffic analysis or other mechanisms. </ins> The following sections describe a DNS record format that achieve these goals.