jiebi/CodeConvo huggingface dataset:
Code change:
Provider (SP) as described in I-D.ietf-mls-architecture.  In particular, we assume the SP provides the following services: <del> A long-term identity key provider which allows clients to </del> <ins> A long-term signature key provider which allows clients to </ins> authenticate protocol messages in a group. A broadcast channel, for each group, which will relay a message to

Related discussion:
text: The credentials we have defined at the moment only contain a single public key and no information regarding what signature scheme that keypair works with (even though the Spec actually says it should include the signature scheme as well). It would be nice, however, to support potential CredentialTypes that, similar to KeyPackages, include multiple supported signature schemes, each accompanied by a corresponding public key. The Key that should be used in any given group is then determined by the CipherSuite of the group (which includes a Signature Scheme). When choosing a KeyPackage of a new member, it has to be one that contains a Credential which supports that Signature Scheme. Note, that I'm not suggesting that this be the case in all Credentials, or even that we change the BasicCredential. I understand that it's possible to have multiple credentials per identity, but in some authentication settings it can be beneficial to have a 1-to-1 mapping between Credential and identity.
KeyPackages don't support multiple signature schemes? In what scenario is it beneficial?
Ah, right. I think that was the case in the past, but you're right, they don't. Of course it's always possible to just bundle a bunch of certificates, each supporting a different signature scheme and then treat that as your "Multi-Scheme Credential" in the grand scheme of things. However, if you end up rotating them a lot, where you have to sign them and potentially store the whole chain for a longer period of time, being able to support multiple signature schemes in only one credential means less overhead.
Credentials are stored in each group's ratchet tree though, so you're keeping a bunch of unnecessary key material in the group's tree which everyone has to store
That's fair. And it's not something you have to do if you don't want to. I'm just proposing for MLS to support that type of Credential in general.
To support hybrid PQ/standard schemes at any point in the future, allowing for multiple schemes is reasonable (in addition to the above arguments for it). Most applications probably will not use the feature, especially to start with, but providing support for just the option is not going to cause any of the problems noted.
PQ schemes can be used by switching the entire group to a new ciphersuite using those schemes.
Code change:
Provider (SP) as described in I-D.ietf-mls-architecture.  In particular, we assume the SP provides the following services: <del> A long-term identity key provider which allows clients to </del> <ins> A long-term signature key provider which allows clients to </ins> authenticate protocol messages in a group. A broadcast channel, for each group, which will relay a message to

Related discussion:
text: Requiring everybody in the group to store a bunch of unused key material isn't reasonable
The statement was not about PQ, but hybrid PQ/standard schemes. Those require use to two signature schemes, for which both types of keying material are used.
Then you need a ciphersuite that specifies a hybrid scheme.
It would be ideal to have a ciphersuite specifying a single hybrid scheme, but even that does not imply use of a single credential, unfortunately. In fact, hybrid schemes may rely on two separate credentials, with the ciphersuite specifying the hybrid algorithm for combining them. Since the "main" method of building a solo hybrid credential is under patent, there is also additional motivation for applications to use two.
I concur with Brendan here. To be consistent with our earlier decisions to (a) keep KeyPackages to one ciphersuite and (b) include the signature algorithm in the ciphersuite, we should keep credentials to one signature algorithm as well. Propose closing this PR without merging.
Discussed at 2020-10-06 interim, TODO: Re-add SignatureScheme enum, re-using the TLS signature schemes Clarify that the main job of a Credential is to provide a public key for verifying messages How it provides the credential might be different per credential type e.g., in BasicCredential, it's provided directly, X509Credential, have to parse the leaf certificate
LGTM with a couple nits.
Code change:
2. <ins> 2.1. </ins> MLS provides a way for _clients_ to form _groups_ within which they can communicate securely.  For example, a set of users might use clients on their phones or laptops to join a group and communicate with each other.  A group may be as small as two clients (e.g., for simple person to person messaging) or as large as tens of thousands. <del> A client that is part of a group is a _member_ of that group. </del> <ins> A client that is part of a group is a _member_ of that group.  As groups change membership and group or member properties, they advance from one _epoch_ to another and the cryptographic state of the group evolves. The group is represented using a _ratchet tree_, which represents the members as the leaves of a tree.  It is used to efficiently encrypt to subsets of the members.  Each member has a _LeafNode_ object in the tree holding the client's identity, credentials, and capabilities. Various messages are used in the evolution from epoch to epoch.  A _Proposal_ message proposes a change to be made in the next epoch, such as adding or removing a member.  A _Commit_ message initiates a new epoch by instructing members of the group to implement a collection of proposals.  Proposals and Commits are collectively called _Handshake messages_.  A _KeyPackage_ provides keys that can be used to add the client to a group, including its LeafNode, and _Signature Key_.  A _Welcome_ message provides a new member to the group with the information to initialize their state for the epoch in which they were added. Of course most (but not all) applications use MLS to send encrypted group messages.  An _application message_ is an MLS message with an arbitrary application payload. Finally, a _PublicMessage_ contains an integrity-protected MLS Handshake message, while a _PrivateMessage_ contains a confidential, integrity-protected Handshake or Application message. For a more detailed explanation of these terms, please consult the MLS protocol specification. 2.2. </ins> In order to communicate securely, users initially interact with services at their disposal to establish the necessary values and

Related discussion:
text: This replaced PR which has broken merge conflicts.
I've reverted this. It was prematurely merged. I'll open a new PR once I have had time to examine this.
This was discussed in the interim today and is the same as the content that was in . Thanks, -rohan Rohan Mahy l Vice President Engineering, Architecture Chat: NAME on Wire Wire - Secure team messaging. Zeta Project Germany GmbH l Rosenthaler Straße 40, 10178 Berlin, Germany Geschäftsführer/Managing Director: Alan Duric HRB 149847 beim Handelsregister Charlottenburg, Berlin VAT-ID DE288748675
That's fine, but I still want to go over it before it merges.
Code change:
1.2. <del> draft-14 - Allow cookies to be longer. </del> <ins> draft-14 Allow cookies to be longer. </ins> draft-13

Related discussion:
text: Lack of a blank line after "draft-14" but before the bullet point causes it to render all on one line: URL This is just a quick patch to make the spacing consistent because apparently Markdown (or, at least whatever is interpreting it there) can be picky. ;) This is just a whitespace fix.
Code change:
frames. The Client Hello datagram exposes version number, source and <del> destination connection IDs, and information in the TLS Client Hello message, including any TLS Server Name Indication (SNI) present, in the clear.  The QUIC PADDING frame shown here may be present to ensure the Client Hello datagram has a minimum size of 1200 octets, to mitigate the possibility of handshake amplification.  Note that the location of PADDING is implementation-dependent, and PADDING frames may not appear in the Initial packet in a coalesced packet. The Server Hello datagram exposes version number, source and destination connection IDs, and information in the TLS Server Hello message. </del> <ins> destination connection IDs in the clear.  Information in the TLS Client Hello frame, including any TLS Server Name Indication (SNI) present, is obfuscated using the Initial secret.  The QUIC PADDING frame shown here may be present to ensure the Client Hello datagram has a minimum size of 1200 octets, to mitigate the possibility of handshake amplification.  Note that the location of PADDING is implementation-dependent, and PADDING frames may not appear in the Initial packet in a coalesced packet. The Server Hello datagram also exposes version number, source and destination connection IDs and information in the TLS Server Hello message which is obfuscated using the Initial secret. </ins> The Initial Completion datagram does not expose any additional information; however, recognizing it can be used to determine that a

Related discussion:
text: However, we also use the terms Server/Client Hello datagram to cover all QUIC Packets of the first two datagrams sent. This term is not used in the transport draft (anymore) and I find it confusing given the TLS terminology. Should we maybe use a different term?
Code change:
datagram.  Omitting the length field MUST only be used for the last record in a datagram. <del> Implementations which send multiple records in the same datagram SHOULD omit the connection id from all but the first record; receiving implementations MUST assume that any subsequent records without connection IDs belong to the same association.  Sending implementations MUST NOT mix records from multiple DTLS associations in the same datagram.  If the second or later record has a connection ID which does not correspond to the same association used for previous records, the rest of the datagram MUST be discarded. </del> <ins> If a connection ID is negotiated, then it MUST be contained in all datagrams.  Sending implementations MUST NOT mix records from multiple DTLS associations in the same datagram.  If the second or later record has a connection ID which does not correspond to the same association used for previous records, the rest of the datagram MUST be discarded. </ins> When expanded, the epoch and sequence number can be combined into an unpacked RecordNumber structure, as shown below:

Related discussion:
text: As proposed on list.
Hanno Becker points out that the current text does not cryptographically protect the CID when we have coalesced packets. I created PR to add this feature, but I think instead we should simply require that all packets have CIDs once the CID is established. This seems like a net reduction in complexity. There would be two changes here: Re-emphasize the point already in the DTLS CID spec that you abort if a CID is expected and none is found. Remove the text about allowing implicit CIDs.
NAME NAME
This was resolved by . Please re-open if that's not the case!
Code change:
5.2.10. <ins> This property specifies whether an application considers it useful to transfer data across multiple paths between the same end hosts. Generally, in most cases, this will improve performance (e.g., achieve greater throughput).  One possible side-effect is increased jitter, which may be problematic for delay-sensitive applications. The recommended default is to have this option. 5.2.11. </ins> This property specifies whether an application wants to use the connection for sending and/or receiving data.  Possible values are:

Related discussion:
text: Notable changes: added control over using multipath (which was a late addition to minset) added a timeout for conn. establishment, separate from the other conn. abort timeout (see ) renamed InitiateWithIdempotentSend into InitiateWithSend, and adjusted the text to recommend declaring idempotence. This addresses the minset function that goes back to TCP's send-with-SYN.
Status: NAME said "LGTM modulo tiny nits" and I think these nits are now addressed. NAME requests something more than just a boolean to enable/disable usage of multiple paths. It seems to me that this needs more discussion, but it also doesn't seem like a show-stopper for the boolean to begin with; I think we can discuss this more after landing this PR. NAME hasn't reacted (or am I missing this), but this has an ok from NAME and NAME In conclusion: I think this is good to go. I'll wait until tomorrow; unless someone speaks up by then, I'll merge this PR.
If you make it a boolean it cannot be used as a selection property, so I do not think that is a good choice. Or how should it be interpreted for the selection?
NAME what do you mean, that it should be a (binary - yes/no) Preference instead? I thought this would be more limiting but I'm fine with this as well.
NAME I meant that it should be a Preference as pointed out in the original comment by NAME I do not understand what a boolean means during selection (is it a requirement or a preference?) I also do not understand what it means in the middle of a connection. You mean you should try and use a single or several subflows for scheduling data, assuming you already have a multipath connection? I guess this is possible, but then the description needs to be more clear that this is what it means. In the appendix about minset your have "Disable MPTCP: "Parallel Use of Multiple Paths" Property." I assume this refers to the Protocol Selection phase? It does not make sense to disable or enable MPTCP in the middle of a connection I think. I guess part of how to specify the property depends on how to interpret this part from the intro to the Managing Connections section: "The application can set and query Connection Properties on a per-Connection basis.
Code change:
5.2.10. <ins> This property specifies whether an application considers it useful to transfer data across multiple paths between the same end hosts. Generally, in most cases, this will improve performance (e.g., achieve greater throughput).  One possible side-effect is increased jitter, which may be problematic for delay-sensitive applications. The recommended default is to have this option. 5.2.11. </ins> This property specifies whether an application wants to use the connection for sending and/or receiving data.  Possible values are:

Related discussion:
text: Connection Properties that are not read-only can be set during pre-establishment (see {{selection-props}}), as well as on connections directly using the SetProperty action" I interpreted this as properties set during pre-establishment are selection properties, but maybe this is not the intention as they may need to be expressed differently? If they are not intended as selection properties, we are missing a selection property for multipath I guess.
NAME Ok. That's what I meant, yes - but I agree that's not covered by the description, it really is a selection preference only as it's written now. OK (though you CAN do it with the "real" API, by closing subflows, but this goes beyond the spec'd protocol, and I'm also not sure it's a good idea, especially when limited to only enabling / disabling it altogether). I would have understood this as in your first interpretation: "properties set during pre-establishment are selection properties".
NAME Closing a subflow is not the same as disabling MPTCP to me. You will still be using MPTCP, only with a single subflow. And you can certainly not open a subflow unless MPTCP is already enabled. But seems we now have a common understanding.
NAME ack, we've converged. I just pushed a commit that turns the "Parallel Use of Multiple Paths" property into a Selection property.
these are a few minor changes to apply, and properties to add (e.g. "disable MPTCP")
this is done, yes?
No. But I'm planning to do a PR to address this issue this week.
Note that this also requires closing , which I re-opened with a concrete proposal to address something from minset.
LGTM modulo tiny nitsSorry, missed this until just now. Looks fine with me, I just have a small question and my 2 cents to the multipath discussion (which we can have at a later point).
Code change:
If present, the IP prefix length in "target" SHALL be preceded by a percent-encoded slash ("/"): "%2F".  The IP prefix length MUST <del> represent an integer between 0 and the length of the IP address in bits, inclusive. </del> <ins> represent a decimal integer between 0 and the length of the IP address in bits, inclusive. </ins> <del> "ipproto" MUST represent an integer between 0 and 255 inclusive, or the wildcard value "*". </del> <ins> "ipproto" MUST represent a decimal integer between 0 and 255 inclusive, or the wildcard value "*". </ins> IP proxies MAY perform access control using the scoping information provided by the client: if the client is not authorized to access any of the destinations included in the scope, then the IP proxy can immediately fail the request. <del> 4.6. </del> <ins> 4.7. </ins> This document defines multiple new capsule types that allow endpoints to exchange IP configuration information.  Both endpoints MAY send any number of these new capsules. <del> 4.6.1. </del> <ins> 4.7.1. </ins> The ADDRESS_ASSIGN capsule (see iana-types for the value of the capsule type) allows an endpoint to inform its peer of the list of IP

Related discussion:
text: I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.
Code change:
tunnel due to a period of inactivity, but they MUST close the request stream when doing so. <ins> A successful response (as defined in Sections resp1 and resp23) indicates that the IP proxy has established an IP tunnel and is willing to proxy IP payloads.  Any response other than a successful response indicates that the request has failed; thus, the client MUST abort the request. </ins> Along with a successful response, the IP proxy can send capsules to assign addresses and advertise routes to the client (capsules).  The client can also assign addresses and advertise routes to the IP proxy for network-to-network routing. <del> By virtue of the definition of the Capsule Protocol (see HTTP-DGRAM), IP proxying requests do not carry any message content.  Similarly, successful IP proxying responses also do not carry any message content. 4.1. </del> <ins> 4.2. </ins> When using HTTP/1.1 H1, an IP proxying request will meet the following requirements:

Related discussion:
text: I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.
Code change:
fall back to some other transport protocol.  In the case of HTTP, this fallback is TLS 1.3 over TCP. <ins> The IETF TAPS specifications I-D.ietf-taps-arch describe a system with a common API for multiple protocols and some of the implications of fallback between these different protocols, specifically precluding fallback to insecure protocols or to weaker versions of secure protocols. </ins> An application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS 1.3 exposes control information to modification and manipulation in the network.  Further

Related discussion:
text: This is a proposal by Gorry to address issue
This works for me.
Should TAPS be cited as an informational ref to an API that is being discussed by the IETF, and which could apply to QUIC - at least to define the primitives needed in an API, and has quite some insight into protocol racing/fallback as described in applicability?
I'd be happy to do so ;-) however we avoided in the end to talk to much about specific of the interfaces or needed nobs. So not sure it fits or where to fit it.... where would you want to say something?
I think the WG should consider writing a short section on this. It's important enough that we have a WG developing relevant specs for how to build APIs and the need for this type of fallback/racing.
I'm not sure the QUIC WG has enough experience to say anything on the matter. The fallback discussion is about how (Application Mapping + QUIC) could fallback to (alternative application mapping + TCP). For HTTP/3 this isn't a straight fallback - if QUIC fails then a different HTTP version over TCP is required. This has consequences for applications that use HTTP/3 as a substrate (MASQUE, WebTransport) which rely on features only it provides like unreliable DATAGRAM. I think the Applicability spec might need to say more here. What I'm trying to highlight is that there isn't a straight shootout between TCP and QUIC. If TAPS frames things like that then I don't know that it helps Applicability.
taps allows you to use the same interface for multiple transports and also provides you a way to state requirements (hard or soft) to restricts the selection of possible transports. In that sense for some application TCP and QUIC might be not make a real difference as long as all features requested are support, e.g reliability and in-order delivery. Still not sure what/if we want to say something in applicability statement...?
NAME we were trying to not focus on http in this document. But I do agree that the fact that there is a different version needed for http to fallback could still be interesting. How about adding as sentence like the add the end of the first paragraph in section 2: OLD In the case of HTTP, this fallback is TLS 1.3 over TCP.