jiebi/CodeConvo huggingface dataset:
Change:
The ECHConfig structure contains the following fields: The version of the structure.  For this specification, that value <del> SHALL be 0xff03.  Clients MUST ignore any ECHConfig structure with </del> <ins> SHALL be 0xff07.  Clients MUST ignore any ECHConfig structure with </ins> a version they do not understand. An opaque byte string whose contents depend on the version of the

Discussion:
Once we have some implementations that interop, we'll go ahead with early codepoint allocation. The new version matches -07, which will be the next draft version we submit. cc NAME NAME
We need to pick some values for the "encryptedclienthello(TBD)" and for the HTTPSSVC RR type before we can do interop. Allocating some values from the private ranges for those before draft-07 is pushed out would be good so we can do some interop testing. (Or for whatever is the next draft for which we want to do interop.)
Change:
DetNet IP flows sent over an DetNet MPLS network.  Aggregation as defined in ip-agg MAY be used to identify an individual DetNet IP flow.  The provisioning of the mapping of DetNet IP flows to DetNet <del> MPLS app-flow information MUST be supported via configuration and the controller plane, see m-cp-considerations. </del> <ins> MPLS app-flow information MUST be supported via configuration, e.g., via the controller plane described in m-cp-considerations. </ins> A relay node MAY be provisioned to handle packets received via the DetNet MPLS data plane as DetNet IP flows.  A single incoming MPLS

Discussion:
import IP over MPLS scenarios from mpls-dp doc, carify non-DetNet IP
Change:
identifiers from EDHOC SHOULD provide mechanisms to update the connection identifier and MAY provide mechanisms to issue several simultaneously active connection identifiers.  See RFC9000 for a non- <del> constrained example of such mechanisms. </del> <ins> constrained example of such mechanisms.  Connection identifiers SHOULD be unpredictable.  Using the same identifier several times is not a problem as long as it is chosen randomly.  Connection identity privacy mechanisms are only useful when there are not fixed identifiers such as IP address or MAC address in the lower layers. </ins> 8.6.

Discussion:
Some additional text on connection id privacy New connections identifiers needs to be unpredictable to provide improved privacy QUIC requirement to not use the same identifier in a connection seems like nonsense that lowers privacy compared to random selection and increases implementation complexity. Christian Amsuss pointed out in a discussion in CORE that connection id privacy often does not make sense in many deployments as there are fixed identifier in lower layers
LGTM
If connection identifiers are predictable (e.g., a sequence) they might be used by an attacker to determine that the two EDHOC sessions came from the same device. We should add a sentence on this. In practice it does not matter unless IP address, MAC address, etc are randomized as well.
Isn´t it covered by sec 8.5?: Essentially, any of the additional data (EADs and CI/CR) can be used to attack privacy, whether anonymity or unlinkability. A side remark is that even with padding, if any of the EADs is a counter, the length of messagex can allow to distinguish high intensity traffic vs low intensity traffic.
Yes, it does. The text is more general then I thought. Should probablt have some guidance on non-predictable connection identifiers. If a device is using a sequence like 0x3489f2, 0x3489f3, 0x3489f4, 0x3489f5 updating the connection identifier is quite useless.
Change:
The User Equipment is the device that a user desires to be attached to a network with full access to all hosts on the network (e.g., to have Internet access).  The User Equipment communication is typically <del> restricted by the Captive Portal Enforcement, described in </del> <ins> restricted by the Enforcement Device, described in </ins> section_capport_enforcement, until site-specific requirements have been met.

Discussion:
We were using "Captive Portal Enforcement", "Captive Portal Enforcement Device" and "Enforcement Device", with varying capitilisation, inconsistently throughout the document. Address that by defining the component as "Captive Portal Enforcement Device", and using that term in section headings, and "Enforcement Device" everywhere else. Fixes issue
Looks good to me
Used in different ways: Captive Portal Enforcement, enforcement device, etc.
I think keeping it shorter is likely better. ? Caps to make it clear it's a first class component in the architecture?
Change:
"candidate-attribute" field defined for ICE.  For example: The IceCandidate object also contains fields to indicate which m= <del> line it should be associated with.  The m line can be identified in one of two ways; either by a m-line index, or a MID.  The m-line index is a zero-based index, with index N referring to the N+1th m-line in the SDP sent by the entity which sent the IceCandidate. The MID uses the "media stream identification", as defined in RFC5888, to identify the m-line.  WebRTC implementations creating an ICE Candidate object MUST populate both of these fields. Implementations receiving an ICE Candidate object SHOULD use the MID if they implement that functionality, or the m-line index, if not. </del> <ins> line it should be associated with.  The m= line can be identified in one of two ways; either by a m= line index, or a MID.  The m= line index is a zero-based index, with index N referring to the N+1th m= line in the SDP sent by the entity which sent the IceCandidate.  The MID uses the "media stream identification" attribute, as defined in RFC5888, Section 4, to identify the m= line.  JSEP implementations creating an ICE Candidate object MUST populate both of these fields. Implementations receiving an ICE Candidate object MUST use the MID if present, or the m= line index, if not (as it could have come from a non-JSEP endpoint). </ins> 3.4.2.

Discussion:
Also, update IceCandidate section to use consistent “m= line” terminology, and also make it clearer that use of MID, if present, is a MUST.
WFM
The current example in S 3.2 refers to SDES, but that's not in JSEP any more. We need a new example.
Change:
reducing the latency involved with restarting the connection.  This of course only applies in cases in which 0-RTT data is safe, when the client is the restarting peer, and when the data to be sent is <del> idempotent. </del> <ins> idempotent.  Using resumption in this way also assumes that the protocol does not accumulate any non-persistent state in association with a connection.  State bound to a connection cannot reliably be transferred to a resumed connection. </ins> The tradeoffs between resumption and keepalive need to be evaluated on a per-application basis.  However, in general applications should

Discussion:
These are pretty big. If you would prefer that I create a PR for each individual commit, that can be done. It turns out that there were a lot of things I found needed work. For instance, this completely redoes the 0-RTT advice.
It did kinda snowball, for which I apologize. I was trying to get something under your nose before I got swamped by meetings. I am also on vacation next week. I'm reading through and there is some really good stuff in the doc. I have started to open issues where I don't think the fixes are so simple.
Aside from the keep-alive tweak and the idempotence change, these are all editorial and LGTM, thanks! The keepalive tweak is also good. Having looked at URL, the text here is a good applicability-appropriate view on what's there now. assuming discussion there converges to mostly the same thing, I'd be happy to merge this. (in the future, no need to make tiny PRs, but splitting into "editorial-rollup" and "substantive editorial changes" would be nice to separate discussion, since the former shouldn't need much of it)Changes look all ready good. Thanks! I just have left one minor comment/question to double-check before we merge.
Change:
HTTP POST request to the WHIP endpoint url. Each ICE server will be returned on a Link header with a "rel" <del> attribribute value of "ice-server" where the Link target URI is the ICE server URL and the credentials are encoded in the Link target </del> <ins> attribute value of "ice-server" where the Link target URI is the ICE server URL and the credentials are encoded in the Link target </ins> attributes as follows: username: If the Link header represents a TURN server, and <del> creadential-type is "password", then this attribute specifies the </del> <ins> credential-type is "password", then this attribute specifies the </ins> username to use with that TURN server. <del> credential: If credential-type attribute is misson or has a </del> <ins> credential: If credential-type attribute is missing or has a </ins> "password" value, the credential attribute represents a long-term authentication password, as described in RFC8489, Section 10.2.

Discussion:
If you find them useful, here are some spelling fixes. The ' PATH ' spelling is confusing, I think it should be ' PATCH ' Also the draft URL points to and older draft. I have been very inspired by WHIP, thank you for giving it to the community.
Change:
compatible with the QUIC version that the client has selected.  If the server cannot select a compatible combination of application protocol and QUIC version, it MUST abort the connection.  A client <del> MUST abort a connection if the server picks an incompatible combination of QUIC version and ALPN identifier. </del> <ins> MUST abort a connection if the server picks an application protocol incompatible with the protocol version being used. </ins> 8.2.

Discussion:
The server doesn't pick a version. The server only picks the application protocol from what the client offered, and it might do that based on the QUIC version that the client picked.
NAME That depends on how you read RFC 7301, doesn't it? Section 3.1 says: I interpret "suitable" as "one of the options that the client proposed", but unfortunately that RFC is not very specific.
That is confusing, but it doesn't mean that the server doesn't pick an ALPN. We do require that it select an ALPN value, and even if it picks one that the client doesn't offer (whether legitimate or not), that doesn't invalidate this text.
No, I was suggesting restoring the sentence that was there before, but with alternate wording to address NAME concern. Now the server MUST abort if it can't pick a proper combination, and the client MUST abort if the server fails to abide by that requirement.
I think removing the sentence entirely is the wrong approach.OK, I see now. Yes, this WFM.
Change:
The protocol specified by this document takes a different approach. It assumes that private origins will co-locate with or hide behind a <del> provider (reverse proxy, application server, etc.) that protects SNIs for all of the domains it hosts.  As a result, SNI protection does not indicate that the client is attempting to reach a private origin, but only that it is going to a particular service provider, which the observer could already tell from the visible IP address. </del> <ins> provider (reverse proxy, application server, etc.) that protects sensitive ClientHello parameters, including the SNI, for all of the domains it hosts.  These co-located servers form an anonymity set wherein all elements have a consistent configuration, e.g., the set of supported application protocols, ciphersuites, TLS versions, and so on.  Usage of this mechanism reveals that a client is connecting to a particular service provider, but does not reveal which server from the anonymity set terminates the connection.  Thus, it leaks no more than what is already visible from the server IP address. </ins> This document specifies a new TLS extension, called Encrypted Client Hello (ECH), that allows clients to encrypt their ClientHello to a

Discussion:
cc NAME
In just a few sentences, let's define the anonymity set and say what it means for connections to end points in this set to be indistignuishable. We might also enumerate non-goals (though we still need consensus on what these are).
I've not yet gotten around to the PR yet, but here's the gist: Attackers: Passive attackers are those which cannot probe, e.g., buggy middleboxes that filter based on plaintext packet contents. Active attackers can probe, e.g., censors. Goals: ECH does not negatively affect any existing security properties of TLS 1.3. ECH connections to servers in the same anonymity set are indistinguishable from one another for passive and active attackers, modulo traffic analysis. (Note: an anonymity set is determined by the client and server parameters, e.g., the SNI, supported application protocols, and so on.) ECH support is secret from passive attackers who don't know the ECH configuration, but not active attackers. ECH usage is secret from passive attackers who don't know the ECH configuration, but not active attackers. More specifically: Passive attackers with a known ECH configuration can distinguish between a connection that negotiates ECH with that configuration and one which does not (GREASEd or using a different configuration). Passive attackers without the ECH configuration cannot distinguish between a connection that negotiates ECH and one which does not (but GREASEd). Active attackers can distinguish between a connection that negotiates ECH and one which does not (but GREASEd).
Yeah this looks good.
From the interim: merge this as a PR and then address censorship separately (if desired).
Change:
The response to the DNS challenge simply acknowledges that the client is ready to fulfill this challenge. <del> The string "dns-01" The "token" value from the authorized key object in the challenge. </del> <ins> The key authorization for this challenge.  This value MUST match the token from the challenge and the client's account key. </ins> <del> On receiving a response, the server MUST verify that the "token" value in the response matches the "token" field in the authorized key object in the challenge.  If they do not match, then the server MUST return an HTTP error in response to the POST request in which the client sent the challenge </del> <ins> On receiving a response, the server MUST verify that the key authorization in the response matches the "token" value in the challenge and the client's account key.  If they do not match, then the server MUST return an HTTP error in response to the POST request in which the client sent the challenge. </ins> To validate a DNS challenge, the server performs the following steps: <del> Compute the SHA-256 digest of the authorized key object </del> <ins> Compute the SHA-256 digest of the key authorization </ins> Query for TXT records under the validation domain name

Discussion:
This PR updates the new challenges so that they no longer use a JSON object dictated by the server. Instead, they use a "key authorization" string that is canonically generated from the token and key for a given challenge. (And also, while we're here, changes "authorized key object" to "key authorization".)
Change:
TLSPlaintext or TLSCiphertext structures, which are processed and transmitted as specified by the current active session state. <del> %%% Handshake Protocol enum { reserved(0), client_hello(1), server_hello(2), session_ticket(4), hello_retry_request(6), server_key_share(7), encrypted_extensions(8), certificate(11), reserved(12), certificate_request(13), reserved(14), certificate_verify(15), reserved(16), server_configuration(17), finished(20), (255) } HandshakeType; </del> <ins> %%% Handshake Protocol enum { hello_request_RESERVED(0), client_hello(1), server_hello(2), session_ticket(4), hello_retry_request(6), server_key_share(7), encrypted_extensions(8), certificate(11), server_key_exchange_RESERVED(12), certificate_request(13), server_hello_done_RESERVED(14), certificate_verify(15), client_key_exchange_RESERVED(16), server_configuration(17), finished(20), (255) } HandshakeType; </ins> The TLS Handshake Protocol messages are presented below in the order they MUST be sent; sending handshake messages in an unexpected order

Discussion:
There are a couple of times the reserved values don't include the string "RESERVED". Can we either note this in the intro or add "RESERVED" to the appropriate places in ContentType and HandshakeType:
If we can remove all the fields suffixed by it would make the enums more easy to read. =)
Change:
If corr (METHOD_CORR mod 4) equals 1 or 3, C_I is omitted, otherwise C_I is not omitted. <del> Generate an ephemeral ECDH key pair as specified in Section 5 of SP-800-56A using the curve in the selected cipher suite and format it as a COSE_Key.  Let G_Y be the 'x' parameter of the COSE_Key. </del> <ins> Generate an ephemeral ECDH key pair using the curve in the selected cipher suite and format it as a COSE_Key.  Let G_Y be the 'x' parameter of the COSE_Key. </ins> Choose a connection identifier C_R and store it for the length of the protocol.

Discussion:
This was suggested in CFRG during the discussion on HPKE Elliptic-Curve-Point-to-Octet-String Conversion. The compact representation used in EDHOC can be used whenever compact output is used in ECDH (which it almost always is). Important to differenctiate between the wire format, the validation done, and the algorithm for multiplication. EDHOC only touch the wire format, and do not loosen any validation requirements or recommend any particular algorithms form multiplication. Suggestion oflline that it might be better to specify that the "y-bit" is set to 0 instead of giving the implementor an option. Suggestion offline that the draft should refer to SECG in addition or instead of NIST.
I made a PR trying to capture the suggestion from CFRG. I think the PR is ready to merge.
on page 14 would it not be suitable to add that IDCREDx = { x5chain : certificate in DER }, for x = I or R,
Very timely comment. I just made an update to this effect, see b5346fb. I didn't want to include this kind of notation as it requires explanation. Is it good enough?
Suggest to give it a bullet as well. Göran Selander schreef op 2021-02-22 11:26: Links: [1] URL [2] URL [3] URL
Change:
second HelloRetryRequest which was sent in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest). <ins> DTLS clients which do not want to receive a Connection ID SHOULD still offer the "connection_id" extension unless there is an application profile to the contrary.  This permits a server which wants to receive a CID to negotiate one. </ins> 5.2. In order to support message loss, reordering, and message

Discussion:
NAME
The text is good for me.
LGTM, but we should confirm on the list.This definitely helps, thanks. It doesn't completely eliminate the possibility of QUIC-LB catastrophic failure, but it makes things way better.
Change:
cryptographic tokens that prove nothing other than that they have been created by a given server in the past ARCHITECTURE. <del> This document describes the issuance protocol for Privacy Pass.  It specifies two variants: one that is privately verifiable based on the oblivious pseudorandom function from OPRF, and one that is publicly verifiable based on the blind RSA signature scheme BLINDRSA. </del> <ins> This document describes the issuance protocol for Privacy Pass built on HTTP.  It specifies two variants: one that is privately verifiable based on the oblivious pseudorandom function from OPRF, and one that is publicly verifiable based on the blind RSA signature scheme BLINDRSA. </ins> This document does not cover the Privacy Pass architecture, including choices that are necessary for ensuring that client privacy leaks.

Discussion:
... I think. I'm double checking to see if there is any other improper HTTP usage.
The Issuance protocol depends on HTTP, so I'd expect this to be cited. Then we get into the HTTP terminology alignment game. For example, where the document says something like should be substituted for as per URL
Change:
The Verifier trusts (or more specifically, the Verifier's security policy is written in a way that configures the Verifier to trust) a manufacturer, or the manufacturer's hardware, so as to be able to <del> appraise the trustworthiness of that manufacturer's devices.  In a typical solution, a Verifier comes to trust an Attester indirectly by having an Endorser (such as a manufacturer) vouch for the Attester's ability to securely generate Evidence. </del> <ins> appraise the trustworthiness of that manufacturer's devices.  Such trust is expressed by storing one or more "trust anchors" in a secure location known as a trust anchor store. As defined in RFC6024, "A trust anchor represents an authoritative entity via a public key and associated data.  The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative."  The Trust Anchor may be a certificate or it may be a raw public key along with additional data if necessary such as its public key algorithm and parameters. In a typical solution, a Verifier comes to trust an Attester indirectly by having an Endorser (such as a manufacturer) vouch for the Attester's ability to securely generate Evidence, in which case the Endorser's key material is stored in the Verifier's trust anchor store. </ins> In some solutions, a Verifier might be configured to directly trust an Attester by having the Verifier have the Attester's key material

Discussion:
Uses text copied from the TEEP arch draft. Addresses Signed-off-by: Dave Thaler
Does “trust anchor store” in Layered Attestation Environments require an introduction?
I advocate taking it out. See and . If / when "trust anchor store" is in the architecture document it should be in the establishment of trust in the basic non-layered Attester. It should be somewhere in section 7.
PR addresses the original issue but there is more needed than just what is in PR to fully address this in my view. Two pieces remain: 1) Currently the trust anchor store is mentioned in the Verifier but not the Relying Party, and appropriate language should be updated in the Relying Party section also. 2) Unlike the TEEP architecture, the Security Consideration section focuses on the attester and so does not mention securing the trust anchor store on the Verifier and Relying Party.
Having merged , the definition of trust-anchor store definition will get moved upwards so that it can be referenced in Relying Party section, and then also a SC paragraph about securing the store.
Change:
4.1. <ins> An Attester consists of at least one Attesting Environment and at least one Target Environment.  In some implementations, the Attesting and Target Environments might be combined.  Other implementations might have multiple Attesting and Target Environments.  One example is a set of components in a boot sequence (e.g., ROM, firmware, OS, and application) where a Target Environment is the Attesting Environment for the next environment in the boot sequence. Claims are collected from Target Environments.  That is, Attesting Environments collect the raw values and the information to be represented in claims.  Attesting Environments then format them appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence. Examples of environments that can be used as Attesting Environments include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), or Hardware Security Modules (HSM). 4.2. </ins> A Composite Attester is an entity composed of multiple sub-entities such that its trustworthiness has to be determined by evaluating all these sub-entities.  Each sub-entity has at least one Attesting

Discussion:
Addresses issue There's no text changes in this PR, text is just moved without modification. Signed-off-by: Dave Thaler
otherwise, the section 4.1 including a lot of content about attester, attesting enviroment and target enviroment are not easy to understand. Or, at least, have some general introduction or reference to section 6 about what is relation between them.
Agree, Section 6 "Two Types of Environments of an Attester" gives the introduction to these terms, but they are used back in section 4.1 "Composite Attester". Something needs to change either move section 6 up, or section 4.1 down.