jiebi/CodeConvo huggingface dataset:
Code change:
does not need to make them accessible to clients.  Clients SHOULD NOT attempt to dereference or manipulate them. <ins> A Resource Directory can report endpoints or groups in lookup that are not hosted at the same address.  While the setup and management of such a distributed system is out of scope for this document, lookup clients MUST be prepared to see arbitrary URIs as registration or group resources in the results. </ins> 7.3. Using the Accept Option, the requester can control whether this list

Related discussion:
text: This contains what I think of the easy fixes to the requirements of replicated RDs. See URL for more discussion, please comment on whether you think those changes are acceptable.
The minimum for interoperability IMO is that client's don't always pick the first choice -- because if they do, no fault tolerance is possible. Do you think that that even this is too much specification of behavior, or did I write more in the PR than what would be needed to satisfy that minimum requirement?
chrysn schreef op 2018-02-01 17:03: Is that so? The first choice of one client is not necessarily the first choice of another when we are confronted with RDs which have contact problems. Several protocols have handled this problem: like dhcp for example. Why not copy that behavior?
I think we're talking about different "first"s here. I'm not concerned with what happens when multiple servers answer the multicast CoAP request. (Led to an interesting chat with PIM people but is not a matter that should concern the RD). What I do think we should give guidance is what happens if the RDAO announces multiple addresses (something explicitly allowed in the current draft), or the URI discovery response contains more than one rt="URL" link Both are within what I think we describe as acceptable server behavior. If clients are unaware and just always pick the first line (because it looks like a zero-or-one situation to the implementers), interoperability issues will arise when two are announced an the first one fails.
Ok, got it, see below chrysn schreef op 2018-02-02 12:11: Yeah, that's a nuisance. Someone seems to know what they want that for, annd probably have some intelligent algorithm to break ties.......... One might say that client MAY choose their RD randomly. I assume that is a multicast response? Then the first response is probably the closest and the best choice. And when one MC response contains multiple RD links, We are not responsible, and something clever is being thought out somewhere, we hope. I think DHCP specifies clients to wait so many seconds before choosing a server. When the first one fails, the client will try the second one, und so weiter ... What am I missing still?
for interoperability, the client behavior when multiple URIs are discovered, or the RD does not answer, need not be specified. The text starts to look more and more like Bonjour
Code change:
A stateless reset uses an entire UDP datagram, starting with the first two bits of the packet header.  The remainder of the first byte <del> and an arbitrary number of bytes following it that are set to unpredictable values.  The last 16 bytes of the datagram contain a Stateless Reset Token. </del> <ins> and an arbitrary number of bytes following it that are set to values that SHOULD be indistinguishable from random.  The last 16 bytes of the datagram contain a Stateless Reset Token. </ins> To entities other than its intended recipient, a stateless reset will appear to be a packet with a short header.  For the stateless reset

Related discussion:
text: I see a couple of places where we require that values have high entropy. For instance of the packet header. The remainder of the first byte and an arbitrary number of bytes following it that are set to unpredictable values. The last 16 bytes of the datagram contain a Stateless Reset Token. and to ensure that it is easier to receive the packet than it is to guess the value correctly. In general, this means that things contain sufficient entropy (so, for instance, you might have a value with some fixed values and some high entropy values). In any case, I think the first of these should be "indistinguishable from random" and the second should be "containing at least 64 bits worth of entropy"
LGTM
Code change:
logically separate entities.  The two functions could of course be integrated into a single service. <del> TWO CHOICES: 1.  Cloud Registrar redirects to Owner Registrar 2. Cloud Registrar returns VOUCHER pinning Owner Register. </del> <ins> There are two different mechanisms for a cloud registrar to handle voucher requests: 1. the Cloud Registrar redirects the request to Owner Registrar for handling 2. the Cloud Registrar returns a voucher pinning the Owner Register and includes additional bootstrapping information embedded in the voucher Both mechanisms are described in detail later in this document. </ins> 2.1.

Related discussion:
text: I find the "??" in the figure confusing. The Cloud Registrar and the MASA could just be shown as adjacent boxes; the explanation in the text is fine. That looks ugly as a single pseudo-sentence, and I'm not sure what it means. A more complete explanation would be good.
Code change:
Associated Destination Connection ID: The Connection ID used to send packets over the path. <del> If multiple packet number spaces are used over the connection, hosts MUST also track the following information. </del> <ins> In Active state, hosts MUST also track the following information: </ins> <del> Path Packet Number Space: The endpoint maintains a separate packet number for sending and receiving packets over this path.  Packet number considerations described in QUIC-TRANSPORT apply within the given path. </del> <ins> Path ID: The endpoint maintains a separate packet number space for sending and receiving packets over this path which is identified by the path ID.  Packet number considerations as described in Section 12.3 of QUIC-TRANSPORT apply within the given path. </ins> In the "Active" state, hosts MUST also track the following information.

Related discussion:
text: From PR from NAME
Let's do another editorial pass and evtl. some re-org first and then address this issue. I think we all already agreed that we only need one of the two. So we only need to decide with name we keep.
I prefer to use the name "Path ID", as it is more intuitive in the context of multipath.
The conflict was solved. LGTM.Sounds good.
Code change:
ensure that names under the split-horizon are correctly signed or place them in an unsigned zone. <del> If an internal zone name (e.g., internal.example.com) is used with this specification and a public certificate is obtained for validation, that internal zone name will exist in Certificate Transparency logs RFC9162.  It should be noted, however, that this specification does not leak individual host names (e.g., www.internal.example.com) into the Certificate Transparancy logs or to public DNS resolvers. </del> <ins> If an internal zone name (e.g., ) is used with this specification and a public certificate is obtained for validation, that internal zone name will exist in Certificate Transparency logs RFC9162.  It should be noted, however, that this specification does not leak individual host names (e.g., ) into the Certificate Transparency logs or to external DNS resolvers. </ins> 10.

Related discussion:
text: Includes: Text adjustments for grammar and clarity Replacing "public" resolver with "external" Changes to references and blockquotes Made diagrams narrower
NAME NAME Please review
Changes look good to me.
Code change:
compatibility purposes.  It MUST be ignored for all purposes.  See TLS13; Appendix D.1 for the rationale for this. <ins> The least significant 2 bytes of the connection epoch value. </ins> The unified header (unified_hdr) is a structure of variable length, as shown in cid_hdr.

Related discussion:
text: Yet another attempt to This builds on Chris's PR but just omits the epoch entirely from the AEAD nonce calculation. This is more consistent with TLS and doesn't require special case reasoning about why we only need to build in the bottom 16 bits. This relies entirely on the keys being different. Needs analysis.
This seems promising.
NAME this LGTM, but there's a conflict. Can you resolve prior to merging? NAME are you OK with the new rationale, and text that allows it to be relaxed in the future?
If I have understood and calculated correctly DTLS 1.3 limits the number of packets in a AES-GCM connection to 2^40.5 compared to 2^64 in DTLS 1.2. This is quite a severe limitation that is not mentioned explicitly. The AEAD limits in themselves are not a problem, but the combination of AEAD limits (2^24.5) and a small epoch (2^16) is a problem. I think this is major problem in some use cases of DTLS. E.g. most 3GPP 5G use cases where DTLS or DTLS/SCTP is used for semi-permanent connections (lasting years) and where the terminating the connection cause severe disturbances. I did not find any discussion about this problem (but I could easily have missed it) It is known that the limit of 2^48 packets in SRTP can be reached and 2^40.5 is significantly smaller than this... If the document was not in such a late stage, I would have suggested to increase the size of the epoch to 32 bits..... I think this and the other problems DTLS 1.3 has with semi-permanent connections has to be solved sooner than later.
NAME thanks for filing this. I hear you about the late stage, but IIRC we never represent the entire epoch on the wire in any case, so it seems like just changing it to 32 bits would be pretty easy, so why not do it now?
How do the chacha20 numbers compare to the AES-GCM ones?
Code change:
compatibility purposes.  It MUST be ignored for all purposes.  See TLS13; Appendix D.1 for the rationale for this. <ins> The least significant 2 bytes of the connection epoch value. </ins> The unified header (unified_hdr) is a structure of variable length, as shown in cid_hdr.

Related discussion:
text: NAME I don't think (D)TLS 1.3 puts any limits on ChaCha20 so my understanding is understanding is that the total number of packets can be protected in the current drafts is ChaCha20 2^64 (2^48 2^16) AES-GCM 2^40.5 (2^24.5 2^16) AES-GCM 2^39 (2^23 * 2^16)
NAME I am all for changing this now. I made a PR that change epoch from uint16 to uint32. As you say, it seems like a pretty easy change to do. Is uint32 the right size?
Unless you think we should do uint64. NAME NAME what would we have to do to make this change?
URL Magnus Westerlund thinks uint64 would be a safer bet.Michael Tüxen suggest to wrap the uint16 epoch instead. That might be an easier solution. I don't see a direct problem in DTLSPlaintext, ACK message, or recordsequencenumber with a uint16 epoch that is allowed to wrap like: 4, 5, ... 2^16-1, 4, 5, ... 2^16-1, 4, 5, ...
NAME NAME NAME since it's through the IESG we would need to at least raise that this change was made after they had approved it. I suspect that doing some kind of 2-week heads up to the WG/IESG that we want to make the change before landing it. But, if we do that or something more drastic that's really up to NAME
I want to point out that allowing wrapping per may not be the best solution if one considers to use the DTLS epoch as part of the input to the TLS exporter as suggested in . Then one want an input that doesn't wrap, and then to ensure that one doesn't practically run into any limits, then an uint64 would be better. An unit32 appears to be sufficient for a quite extreme use case with minimal messages size (which is one DTLS record with 4 byte user message) and high bandwidth (10 Gbps) sustained over a period of more than 5 years before the epoch would wrap.
Code change:
compatibility purposes.  It MUST be ignored for all purposes.  See TLS13; Appendix D.1 for the rationale for this. <ins> The least significant 2 bytes of the connection epoch value. </ins> The unified header (unified_hdr) is a structure of variable length, as shown in cid_hdr.

Related discussion:
text: However, to my understanding the full epoch value are so rarely included in transmitted DTLS messages that its size have minimal implication on the overhead that it is not worth saving 4-bytes to be certain to have eliminated any practical limitation.
I think a 2-week WGLC and notifying the IESG will suffice.
FYI. We have now run into quite many problems with the interworking of semi-permanent DTLS/SCTP connections (lasting years) and DTLS 1.3: No Diffie-Hellman rekeying No post-handshake server authentication No rekeying of the exporter_secret 2^40.5 packets limit 2 minute MSL requirement 2^38.5 byte SCTP user message size limit Our initial plan was to just replace DTLS 1.2 with DTLS 1.3, leave DTLS/SCTP as is, but as the problems keep adding up we are now startnig to consider quite big changes to DTLS/SCTP 1.3 to make this work: URL Using new DTLS connections instead of KeyUpdate could potentially address the first five, but is a significant change.
Hi, Based on the problems long-lived DTLS/SCTP had with DTLS 1.3 (as well as DTLS 1.2 without renegotiation and respecting AEAD limits) we restructured DTLS/SCTP (RFC6083bis) to use parallel connections instead of relying on renegotiation and post-handshake messages. We think this quite easily solves all the problems we had without requiring any updates of DTLS 1.3. It also makes DTLS/SCTP less dependant on version specific DTLS mechanisms. It will hopefully work without changes with any future DTLS 1.4. URL We can now firmly RECOMMEND DTLS 1.3 which I think is very important. 5G is to a large degree replacing or complementing IPsec with TLS, DTLS, and DTLS/SCTP. I will do my best to transition 3GPP to DTLS 1.3 asap. FYI, 3GPP DTLS/SCTP associations have very long lifetimes (can be years), strive for five nines (99.999%) availability and cannot be teared down without causing major disruptions.
Code change:
compatibility purposes.  It MUST be ignored for all purposes.  See TLS13; Appendix D.1 for the rationale for this. <ins> The least significant 2 bytes of the connection epoch value. </ins> The unified header (unified_hdr) is a structure of variable length, as shown in cid_hdr.

Related discussion:
text: With such long lifetimes we think mutual reauthentication, rekeying of the SCTP-AUTH key, and forcing attackers to dynamic key exfiltration [RFC7624] are required features. I still think should be done. 2^40.5 packets is quite limiting.
Seems OK.Thanks -- this LGTM. We'll need to do a brief consensus call given the type of change.
Code change:
The most appropriate error code (error-codes) SHOULD be included in the frame that signals the error.  Where this specification identifies error conditions, it also identifies the error code that <del> is used. </del> <ins> is used; though these are worded as requirements, different implementation strategies might lead to different errors being reported.  In particular, an endpoint MAY use any applicable error code when it detects an error condition; a generic error code (such as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place of specific error codes. </ins> A stateless reset (stateless-reset) is not suitable for any error that can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame.

Related discussion:
text: This just writes down what was proposed in .
Looks fine, but what about some guidance on stream vs connection errors? And also the principle of nearly always choosing a hard protocol violation error, or a more granular error with same effect?
Stream vs. connection is something that application protocols (like HTTP) need to worry about. The transport only concerns itself with connection errors. The idea that you pick the most helpful error is not something that we need to codify (in my view).
Isn't that worth mentioning? Or do we already have such text?
This is already discussed in Section 11, which makes me wonder if it would make more sense for text on this PR to be placed there too.
This I do not disagree with. I was merely suggesting that we explain why, as a general rule, a hard error is preferred as a design principle, not the nature of the error message which I do think should have a large degree of freedom.
Maybe there is a followup needed for the HTTP draft. If the principles are generally the same, we can copy the text and then add some more to cover the idea that we make most errors fatal to the connection rather than the stream.
I like Lucas suggestion of adding this text to the existing and already fairly complete text in section 11.
I moved the second paragraph up to the error handling section, but the text about how codes are selected really belongs with the codes themselves.
We don't really have any real principles that we agree on for deciding what error codes we are describing. Proposal: if the error carries distinct semantics (like stream rejection in HTTP), then it gets a new error code if the error is frequent or particularly significant, then it gets a new error code otherwise, target a more generic error code that identifies the broad area of the protocol finally, if there is no more specific applicable error code, use PROTOCOL_VIOLATION
is example of an issue discussed where it would have been useful to have principles.
Code change:
This document defines an extension to DTLS-SRTP called SRTP EKT Key Transport which enables secure transport of EKT keying material from <del> one DTLS-SRTP peer to another.  This allows those peers to process EKT keying material in SRTP (or SRTCP) and retrieve the embedded SRTP keying material.  This combination of protocols is valuable because it combines the advantages of DTLS, which has strong authentication of the endpoint and flexibility, along with allowing secure multiparty RTP with loose coordination and efficient communication of per-source keys. </del> <ins> the DTLS-SRTP peer in the server role to the client.  This allows those peers to process EKT keying material in SRTP (or SRTCP) and retrieve the embedded SRTP keying material.  This combination of protocols is valuable because it combines the advantages of DTLS, which has strong authentication of the endpoint and flexibility, along with allowing secure multiparty RTP with loose coordination and efficient communication of per-source keys. </ins> 5.1.

Related discussion:
text: This is much more compatible with extensibility patterns in TLS stacks, and in a way that is very forward-compatible with the forthcoming DTLS 1.3, while still being implementable in pre-1.3 stacks. DTLS 1.3 has a notion of post-handshake handshake messages, like and , which are acknoweldged with an message. The framework described here simply sends as yet another post-handshake message. Depends on
r? NAME
I have a bunch of comments but really I could live with this like you have it now.
Code change:
The following structure is used to fully describe the data transmitted in plaintexts or ciphertexts. <ins> The following figure illustrates how the various structures described in this section relate to each other, and the high-level operations used to produce and consume them: </ins> 7.1. MLSMessageContent is authenticated using the MLSMessageAuth

Related discussion:
text: I drew this to help explain the relevant patch in MLSpp to someone, and thought it might be helpful to other folks.
Excellent! This is a very nice addition to explain the design introduced .
Code change:
7.1.10. <ins> isolateSession Boolean false When set to true, this property will initiate new Connections using as little cached information (such as session tickets or cookies) as possible from previous connections that are not entangled with it. Any state generated by this Connection will only be shared with entangled connections.  Cloned Connections will use saved state from within the Connection Group. Note that this does not guarantee no leakage of information, as implementations may not be able to fully isolate all caches (e.g. RTT estimates).  Note that this property may degrade connection performance. 7.1.11. </ins> The following generic Connection Properties are read-only, i.e. they cannot be changed by an application. <del> 7.1.10.1. </del> <ins> 7.1.11.1. </ins> zeroRttMsgMaxLen

Related discussion:
text: There are many ways to do this, but this one mimics the "private browsing" paradigm" as I understand it.
Can you say more? I read as specifically about flushing state, not Connection Group vs. Connection issues generally. This is not literally "flushing" the state but I've update taps-interface to reflect this design while, I think, preserving the spirit of the original text.
Connection Groups used to be about state and context sharing as well as entanglement. Now it's about entanglement. We need to rename Connection Groups ("connection contexts"?) in the architecture to replace the existing "group" concept, and to retain "connection group" in the API for entanglement.
Seems like this could be 360 degrees of rotation in our thinking? (which could be OK, NEAT was written to specify both contexts and flow groups). Let's try some definitions here and see if we converge...
I think brings this back in synch again so no need to rename, possibly the last part of this section in architecture should be removed though as we do not have fine-grained control
Section 9.1 of taps-impl loosely refers to the need for an interface to "flush protocol state" to preserve anonymity, but such a capability is not in taps-interface.
I don't like this text: "Applications must have a way to flush protocol cache state if desired. This may be necessary, for example, if application-layer identifiers rotate and clients wish to avoid linkability via trackable TLS tickets or TFO cookies." Those of you who know me, would immediately see a "MUST"..."if desired." and a "may be necessary". My suggestion is that this digs too deep, and we should remove the text. I could also live with something more neutral though: Note: There are case where applications need to flush protocol cache state, for example, if application-layer identifiers rotate and a client wishes to avoid linkability of trackable TLS tickets or TFO cookies.
I'm fine to have the more neutral sentence proposed by Gorry. I don't think we should specify an interface for it but I think it's good to mention.
I agree that the best approach is to make it more neutral. The other option would be to say that this interface is implementation specific. For sure, we do not want it in the API I think.