Question: versions are four-byte sequences with no additional constraints on format.  Leading zeros SHOULD be omitted for brevity. <del> Syntax: </del> <ins> Syntax of the "quic" parameter value: </ins> Where multiple versions are listed, the order of the values reflects the server's preference (with the first value being the most

The "list of versions" situation does not change, if you only support one version you would write: If you support multiple, you would still use one parameter, but you have to quote it since a comma is not valid in a .
According to URL, the Alt-Svc parameter value can be unquoted: This means that this can be written: instead of only: The current text in URL forbids the unquoted variant which is an additional constraint on the RFC 7838 grammar. Should unquoted parameter values also be permitted? Note that this does not change the situation when multiple versions are supported since an unquoted "token" type is not allowed to contain commas. See also the discussion in .
RFC 7838 allows unquoted strings, but there's nothing preventing new specifications of Alt-Svc parameters from being more restrictive. I'm not sure the added flexibility of allowing unquoted versions buys us much here, and it comes at an implementation cost.
If alt-svc can be specified in configuration files, it is likely to result in interop issues if unquoted is not permitted.
I support allowing unquoted token for alt-svc quic parameter. quic=1 and quic="1" are semantically the same, and there is no reason to disallow unquoted token. Moreover, requiring quoted-string means that we cannot use generic alt-svc parser because such parser can parse quic=1 without an error. You need to write your own parser to detect that the DQUOTE is really there. If you think that detecting it is not necessary, then requiring quoted-string is not necessary in the first place.
People and implementers will be surprised (and do wrong) if the rules and constraints of RFC7838 aren't kept.
To highlight my earlier point, on slack the following was posted The issue appears to not be the unquoted ma=3600, but it does suggest we will see unquoted strings in the wild, and URL is said to also use unquoted ma=3600.
But that's the ma= field, not the quic= field, right? (This issue is about the quic= field, I think)
As I said elsewhere, the current text in draft-23 stems from a Structured Headers issue related to wanting to advertise multiple versions of QUIC. URL Alt-Svc isn't a structured one but if it were (e.g.


Question: versions are four-byte sequences with no additional constraints on format.  Leading zeros SHOULD be omitted for brevity. <del> Syntax: </del> <ins> Syntax of the "quic" parameter value: </ins> Where multiple versions are listed, the order of the values reflects the server's preference (with the first value being the most

if someone wanted to write a generic Structured Header parser) then there was a danger that the rules preventing dictionary key repetition would have prevented an endpoint sending multiple parameters e.g. . To mitigate the risk, the quic parameter was changed to a DQUOTED comma-separated list as part of URL This issue addresses the correctness within the Alt-Svc spec but does it reopen the can related to Structured Headers?
I think that the problem here is independent from whether structured headers should be applied or not. - Structured header issue: duplicate keys. - Invalid grammar according to RFC 7838 since "token" does not include commas. - valid grammar according to both RFC 7838 and the QUIC description. However, if only a single version has to be advertised, then the quoting is not necessary: - valid grammar according to both RFC 7838 and the QUIC description. - valid grammar according to both RFC 7838, but QUIC currently forbids it. In I proposed to fix the grammar (editorial issue). However, at the same time I could also make the grammar match RFC 7838 (the last bullet point above). NAME I would mind not making the semantics more restrictive (e.g. restricting the values of the QUIC parameter to hexadecimal only), but restricting the parser grammar would impose extra restrictions on those who have to generate the header. It is conceivable that implementations will continue accepting the RFC 7838 grammar, and end up accepting while others would reject it and accept only. By making sure that the grammars align, I hope that this becomes a non-issue. So far NAME NAME and NAME seems to support this proposal and NAME is not sure. Can this be considered consensus? :smiley:


Question: to those mailing lists should be given.  An example of this is at https://datatracker.ietf.org/wg/quic/charter/. <del> 2.3.1. One important policy is the IETF IPR policy (see RFC5378, RFC3979, and RFC4879).  Part of this policy requires making contributors aware of the policy. The IETF Trust license file for open source repositories [5] MUST be included prominently in any document repository. Including this information in the CONTRIBUTING file is sufficient. In addition to the boilerplate text there can be a benefit to including pointers to other working group materials, the IETF datatracker, specific drafts, or websites.  Adding such text is at the discretion of the Working Group Chairs. </del> 3. A Working Group Chairs are responsible for determining how to best

I was tempted to remove the entire section on administrative policies, though left it as is. NAME what do you think?
Yeah, I figured it best to start small. Let me know if you need anything else before merging!
NAME Interesting that the circle CI build ran on the merge, but not the PR. I didn't see any build failures reported before it merged, but I just got the email reporting a missed reference. Maybe there are some tweaks you need to apply over there as owner of the org.
Yeah, I'll fix it. Thanks for letting me know!
I was thinking of being a little more aggressive about removing some of the text, with matching PRs for the other work, but this works.


Question: encapsulation key "enc". Construct associated data, "aad", by concatenating the values of <del> "keyID", "kdfID", and "aeadID", as 8-, 16- and 16-bit integers respectively, each in network byte order. </del> <ins> "keyID", "kemID", "kdfID", and "aeadID", as one 8-bit integer and three 16-bit integers, respectively, each in network byte order. </ins> Encrypt (seal) "request" with "aad" as associated data using "context", yielding ciphertext "ct".

and . Given (either assuming a fixed key ID, or looking up the KEM based on key ID), I think this is a nice simplification. It also authenticates more, even if redundant. (The kemID is already part of the HPKE key schedule.) I implemented this change and it's straightforward.
Currently, an encapsulated request carries a key ID which maps to a KEM key that determines the size of the encapsulated public key in a request. This means that code parsing a request needs to know the ID -> KEM mapping in order to parse things correctly, which is somewhat annoying. I propose we add KEMID to the request so that this mapping isn't needed to just parse the message. As a bonus, that would also fold in the KEMID explicitly into the AAD alongside the KDFID and AEADID.
We currently length-prefix it, but we don't have to. Think about this a little.
Both the public key and encapsulated secret are fixed length. I think making these fixed length on the wire is good. However, it does require the parsing code to know the corresponding size, which depends on the KEM. This requires there to be a function to map the kem_id to the corresponding size(s). NAME do you have such an API in your implementation? I have one in mine, which would make this pretty straightforward to implement.


Question: semantics and encodings for any version-specific field.  In particular, different packet protection keys might be used for different versions.  Servers that do not support a particular version <del> are unlikely to be able to decrypt the payload of the packet. Servers SHOULD NOT attempt to decode or decrypt a packet from an unknown version, but instead send a Version Negotiation packet, provided that the packet is sufficiently long. </del> <ins> are unlikely to be able to decrypt the payload of the packet or properly interpret the result.  Servers SHOULD respond with a Version Negotiation packet, provided that the datagram is sufficiently long. </ins> Packets with a supported version, or no version field, are matched to a connection using the connection ID or - for packets with zero-

instead of saying servers SHOULD NOT attempt to parse unknown versions, stick with the factual statement that they will likely be unable to do so. Flips the SHOULD to the second half of the sentence, the expected response. I believe this is editorial, since we're not modifying expected behavior, but it's touching normative language, so please speak up if you're not convinced.
Actually, it seems like there should be a normative MUST NOT attempt.
I would have said "cannot". The contents are unknown, after all. Attempting to prohibit someone from doing something impossible seems like it might be unnecessary (or at least futile). Edit: of course, this change avoids having to deal with that question, which is better.
Why do you say it's impossible? You could simply hope that version n+1 was the same as version n in terms of structure and try to parse it as that, ignoring the version number.
Which is why the PR says "unlikely," not "impossible." But the impossible thing is for the server to know whether it's doing things correctly.
Right, but my point is that we should prohibit trying, not just give people advice that it's dumb.
(Broken out of .) This seems like tuning? Or is the intention to protect the endpoint from an attack, please explain the SHOULD.
encodings for any version-specific field. In particular, different packet protection keys might be used for different versions. Servers that do not support a particular version are unlikely to be able to decrypt the payload of the packet. Servers SHOULD NOT attempt to decode or decrypt a packet from an unknown version, but instead send a Version Negotiation packet, provided that the packet is sufficiently long. I'm having trouble seeing what's needed here. The endpoint has received a packet professing to be in a version it does not understand. It can't know the semantics or encoding of any field there -- and the paragraph already explains that. Yes, I'm sure there are potential attacks in interpreting a packet of unknown provenance and unknown semantics against a different set of semantics and expectations, but I'm not convinced we need to explain them. The text recommends sending a Version Negotiation packet, which seems like the only sensible response.
This refers to .


Question: semantics and encodings for any version-specific field.  In particular, different packet protection keys might be used for different versions.  Servers that do not support a particular version <del> are unlikely to be able to decrypt the payload of the packet. Servers SHOULD NOT attempt to decode or decrypt a packet from an unknown version, but instead send a Version Negotiation packet, provided that the packet is sufficiently long. </del> <ins> are unlikely to be able to decrypt the payload of the packet or properly interpret the result.  Servers SHOULD respond with a Version Negotiation packet, provided that the datagram is sufficiently long. </ins> Packets with a supported version, or no version field, are matched to a connection using the connection ID or - for packets with zero-

NAME
I'm looking for two things: (i) I think this ought to clarify the intention for the SHOULD, I suspect it is clear to those working on this part, but not clear to me why this is a recommendation - i.e., specifically can you give me a use-case of why the Server would otherwise USE information from a packet from an unknown version, unless the intention is to say the server shouldn't waste resources to do try to do this? (ii) I think this implies understanding of Section 14.1 later in the spec, and a ref would help. So... Is it equally true that.. "Servers MUST NOT use the contents of a packet with an unknown version, and SHOULD NOT decrypt this packet, but instead send a Version Negotiation packet, provided that the packet is sufficiently long (see Section 14.1)."? Or perhaps simply explain something like: "Servers SHOULD NOT commit resources to attempt to decode or decrypt a packet from an unknown version, but instead send a Version Negotiation packet, provided that the packet is sufficiently long (see Section 14.1)."?
Fundamentally, it's a caution against assumptions which could prove incorrect, such as "this looks like an unencrypted TLS ClientHello, so I can go find the field that contains...." The server will either process information in a way that could be used maliciously, or the server will generate a response that won't be understood by the client. Ideally, this would be a MUST, except that it's entirely unenforceable by the client what the server does internally. Perhaps the right solution here is to remove the normative language with regard to that piece and stick to the statement of fact we already have:
That approach seems fine.


Question: as expected. Form a URI by populating the URI template RFC6570 <del> "{scheme}://{domain}/.well-known/acme-challenge/{token}", where: * the scheme field is set to "http" if the "tls" field in the response is present and set to false, and "https" otherwise; * the </del> <ins> "http://{domain}/.well-known/acme-challenge/{token}", where: * the </ins> domain field is set to the domain name being verified; and * the token field is set to the token in the authorized key object.

On the mailing list, NAME and NAME pointed out some risks arising from the default virtual host behavior of some web servers. This PR integrates the changes they suggest, namely (1) removing the "tls" option from the challenge, and (2) adding iterations to the challenge. This PR is based on top of and .
Sorry, feel free to tell me to go away, but reading the backing decision to drop HTTPS for SimpleHTTP doesn't make sense to me. If I understand everything correctly, you control the originator of the HTTPS requests and the requests are always sent to domains. So why can't you just enforce to always send the Host header and this wouldn't be an issue?
From : behaviour that if a default TLS/HTTPS virtual host is not configured explicitly, one will be selected based on the ordering of vhosts in the webserver configuration (in practice, this often amounts to alphabetical ordering of files in a configuration directory). As far as I know Apache does the exact same thing for nonencrypted HTTP hosts (this is also acknowledged by a later mail in the thread), so the reasoning is a little weird. I suppose the idea is that hosters are more likely to have HTTP configured correctly rather than HTTPS?
The section on the "" registry says that "Fields marked as "client configurable" may be included in a new-account request". This seems like a copy-paste-o, and perhaps should say that such fields may be included in a new-order request.
Good catch. I opened URL to fix. Thanks! Apache (and I gather nginx too) have the subtle and non-intuitive behaviour that if a default TLS/HTTPS virtual host is not configured explicitly, one will be selected based on the ordering of vhosts in the webserver configuration (in practice, this often amounts to alphabetical ordering of files in a configuration directory). URL URL This creates a vulnerability for SimpleHTTP and DVSNI in any multiple-tenant virtual hosting environment that failed to explicitly select a default vhost [1]. The vulnerability allows one tenant (typically one with the alphabetically lowest domain name -- a situation that may be easy for an attacker to arrange) to obtain certificates for other tenants.


Question: as expected. Form a URI by populating the URI template RFC6570 <del> "{scheme}://{domain}/.well-known/acme-challenge/{token}", where: * the scheme field is set to "http" if the "tls" field in the response is present and set to false, and "https" otherwise; * the </del> <ins> "http://{domain}/.well-known/acme-challenge/{token}", where: * the </ins> domain field is set to the domain name being verified; and * the token field is set to the token in the authorized key object.

The exact conditions for the vulerability vary: SimpleHTTP is vulnerable if no default vhost is set explicitly, the server accepts the "tls": true parameter as currently specified, and the domains served over TLS/HTTPS are a strict subset of those served over HTTP. DVSNI is vulnerable if no default vhost is set explicitly, and the hosting environment provides a way for tenants to upload arbitrary certificates to be served on their vhost. James Kasten and Alex Halderman have done great work proposing a fix for DVSNI: URL That fix also has some significant performance benefits on systems with many virtual hosts, and the resulting challenge type should perhaps be called DVSNI2. The simplest fix for SimpleHTTP is to remove the "tls" option from the client's SimpleHTTP response, and require that the challenge be completed on port 80. URL Alternatively, the protocol could allow the server to specify which ports it will perform SimpleHTTP and SimpleHTTPS requests on; HTTPS on port 443 SHOULD be avoided unless the CA can confirm that the server has an explicitly configured default vhost. The above diffs are currently against Let's Encrypt's version of the ACME spec, we'll be happy to rebase them against the IETF version upon request. [1] though I haven't confirmed it, it's possible that sites that attempted to set a default vhost are vulernable if they followed advice like this when doing so: URL ; an attacker need only sign up with a lexicographically lower name on that hosting platform to obtain control of the default. Peter Eckersley EMAIL Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993


Question: Extensions that add a label that is intended for use with EXI need to create a new XSD Schema that includes all the labels in the IANA <del> registry then allocate a new EXI schemaId value.  Moving to the next letter in the alphabet is the suggested way to create the new value for the EXI schemaId.  Any labels with previously blank ID values SHOULD be updated in the IANA table to have their ID set to this new schemaId value. </del> <ins> registry and then allocate a new EXI schemaId value.  Moving to the next letter in the alphabet is the suggested way to create the new value for the EXI schemaId.  Any labels with previously blank ID values SHOULD be updated in the IANA table to have their ID set to this new schemaId value. </ins> Extensions that are mandatory to understand to correctly process the Pack MUST have a label name that ends with the '_' character.

Set of small editorial tweaks and aligned fragment text with new way of positioning base values
LGTM ( other than we need to decide if we use field or attribute but we can do that as separate PR)


Question: detected using heuristics similar to those used to detect TLS over TCP.  A client initiating a connection may also send data in 0-RTT packets directly after the Initial packet containing the TLS Client <del> Hello.  Since these packets may be reordered in the network, 0-RTT </del> <ins> Hello.  Since packets may be reordered or lost in the network, 0-RTT </ins> packets could be seen before the Initial packet. Note that in this version of QUIC, clients send Initial packets

This goes to the end of "Server Name Indication" Some changes are attempts at clarifications, but I could have incorrectly clarified something, so feel free to reject changes.


Question: Release messages can indicate one or more reasons using elective options.  The following options are defined: <del> The elective Bad-Default-Uri-Host Option indicates that the default indicated by the CSM Default-Uri-Host Option is unlikely to be useful for this server. </del> The elective Alternative-Address Option requests the peer to instead open a connection of the same scheme as the present connection to the alternative transport address given.  Its value is in the form

The next pass will add text related to the default URI-Host for TLS SNI cases.


Question: affects the direction property of the associated "m=" section on future calls to createOffer and createAnswer.  The permitted values for direction are "recvonly", "sendrecv", "sendonly", and "inactive", <del> mirroring the identically named directional attributes defined in </del> <ins> mirroring the identically named direction attributes defined in </ins> RFC4566. When creating offers, the transceiver direction is directly reflected

Several small updates: Issue 15: local media state, local resources correct, removed comment. - Issue 16: updated wording to use 'calling this method', removed comments, - Issue 17: changed stopTransceiver to stop, removed comments, - Issue 18: changed 'directional attribute' to 'direction attribute', removed comments,
LGTM once lands
18) [rfced] Section 4.2.5: We see "direction attribute" but not "directional attribute" in RFC 3264. Will this text be clear to readers? (We ask because we also see "A direction attribute, determined by applying the rules regarding the offered direction specified in [RFC3264], Section 6.1" in Section 5.3.1 of this document.) Original: More specifically, it indicates the [RFC3264] directional attribute of the associated m= section in the last applied answer (including provisional answers), with "send" and "recv" directions reversed if it was a remote answer.
This should indeed be , as that's the terminology used by 3264.
NAME please close this issue once you consider it resolved.
17) [rfced] Section 4.2.2: Will "stopTransceiver" be clear to readers? We could not find this string elsewhere in this document, anywhere else in this cluster of documents, in any published RFC, or in google searches. Original: The stopped property indicates whether the transceiver has been stopped, either by a call to stopTransceiver or by applying an answer that rejects the associated m= section.
This should be , rather than .
NAME please close this issue once you consider it resolved.
16) [rfced] Section 4.1.16: Should "The effects of this method call" be "The effects of calling this method," and should "This call" be "Calling this method"? Original: The effects of this method call depend on when it is invoked, and differ depending on which specific parameters are changed: ... This call may result in a change to the state of the ICE Agent.
SGTM
NAME please close this issue once you consider it resolved.
15) [rfced] Section 4.1.10: Please confirm that "local media state" and "local resources" (as opposed to remote) are correct in the context of setRemoteDescription.


Question: affects the direction property of the associated "m=" section on future calls to createOffer and createAnswer.  The permitted values for direction are "recvonly", "sendrecv", "sendonly", and "inactive", <del> mirroring the identically named directional attributes defined in </del> <ins> mirroring the identically named direction attributes defined in </ins> RFC4566. When creating offers, the transceiver direction is directly reflected

(We ask because we see identical wording in Section 4.1.9 ("setLocalDescription").) Original: This API changes the local media state; among other things, it sets up local resources for sending and encoding media.
yes, this is correct
NAME please close this issue once you consider it resolved.
12) [rfced] Section 4.1.8.1: We had trouble with this sentence. If neither suggestion below is correct, please clarify. Original: While this could also be done with a "sendonly" pranswer, followed by a "sendrecv" answer, the initial pranswer leaves the offer-answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer, if followed by a "sendrecv" answer the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer followed by a "sendrecv" answer, the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time.
suggestion seems right


Question: Most applications operating over IP networks and requiring latency this low use the Real-time Transport Protocol (RTP) RFC3550 or WebRTC <del> RFC8825, which uses RTP for the media transport as well as several other protocols necessary for safe operation in browsers. </del> <ins> RFC8825, which uses RTP as its Media Transport Protocol, along with several other protocols necessary for safe operation in browsers. </ins> Worth noting is that many applications for ultra low-latency delivery do not need to scale to more than a few users at a time, which

NAME - several things here. we probably don't need all of the descriptive text - the idea is that we'd say "assume roughly this protocol stack, and here's what's not included" if distinguishing between "transport protocol" and "media transport protocol" makes sense, that probably needs to be reflected elsewhere in the document (like, a lot of elsewheres) If this approach works, it could either be in the transport protocol section, or in the one you're thinking of for
I don't think there will be a lot of places. We need to pay attention to only the places where we are explicitly referring to the media transport protocol. The rest can stay the same IMO.
NAME - I couldn't reply to this inline, but I looked through the document (searching for "transport protocol", and you're right. I found one place in Section 4.1, and changed the description of RTP as a transport protocol to RTP as a media transport protocol. NAME - Section 4.1 is before where my explanation is now - if this PR makes sense to you, the explanation probably DOES belong much earlier in the doc, perhaps in .
I'm merging this, based on Ali's review.
We want a paragraph to say something about scope along the lines of: This document is for endpoints delivering streaming media traffic. This can include intermediaries like CDNs as well as content owners and end users, plus their device and player providers. We think this can help address a few issues from last call/iesg review, including: (more to be linked as we notice them)
Consider adding a subsection in the introduction about things that are out of scope, and (for extra credit), why they are out of scope.
from NAME 's review (URL) Section 6.1. UDP and Its Behavior UDP is also used for encrypted tunnels (OpenVPN, Wireguard, etc.). Does encrypted tunneling really have no operational impact on streaming apps other than circuit breakers? (I am thinking about 4K streaming over OpenVPN and the like.)
Not sure if this is really about scope clarification? I think this section is intending to talk about usage as part of a transport protocol, but tunnels are sort of more like a path overlay issue or something (might affect mtu, extra hops with extra things that can go wrong, etc.).


Question: Most applications operating over IP networks and requiring latency this low use the Real-time Transport Protocol (RTP) RFC3550 or WebRTC <del> RFC8825, which uses RTP for the media transport as well as several other protocols necessary for safe operation in browsers. </del> <ins> RFC8825, which uses RTP as its Media Transport Protocol, along with several other protocols necessary for safe operation in browsers. </ins> Worth noting is that many applications for ultra low-latency delivery do not need to scale to more than a few users at a time, which

NAME - I'm looking more closely at this issue, and I think text that I put in another (individual) draft may be useful here as well. I'll add it in this section (making the obvious substitutions), and I'll see what NAME and NAME think (after the holiday weekend), and then check back with you. If it works for people, the result will likely be clearer to many readers. Reviewer: Michael Scharf Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC EMAIL if you reply to or forward this review. This informational document surveys network and transport protocol issues that affect quality of experience for streaming applications, in particular video. The overview covers many topics across different technologies. Readers may only be familiar with a subset of these topics and could therefore learn quite a bit from this kind of tutorial. Nonetheless, it remains somewhat unclear what the actual objective of some of the text is. For some topics, quite a bit of technical background is provided, but the discussion is not really comprehensive. In many sections, the document neither derives technical challenges, nor system/protocol requirements, nor practical usage guidance. It is just a kind of tutorial. Quite a bit of text also presents ongoing IETF work, and an RFC with this scope may thus get outdated soon. Section 6.2 deals with topics owned by TCPM. In similar past documents, I have asked for a TCPM presentation prior to an IETF last call in order to ensure that owners of running code are in the loop. I believe this strategy has worked well in the past. Having said this, as TSV-ART reviewer I don't strongly disagree with a publication. All these issues may just be OK for an informational RFC. Some more specific comments: Section 3.2.1. Recognizing Changes from an Expected Baseline This section apparently assumes relatively static path properties, e.g., fixed network connectivity.


Question: Most applications operating over IP networks and requiring latency this low use the Real-time Transport Protocol (RTP) RFC3550 or WebRTC <del> RFC8825, which uses RTP for the media transport as well as several other protocols necessary for safe operation in browsers. </del> <ins> RFC8825, which uses RTP as its Media Transport Protocol, along with several other protocols necessary for safe operation in browsers. </ins> Worth noting is that many applications for ultra low-latency delivery do not need to scale to more than a few users at a time, which

It would be more useful to analyze the impact of Wifi and 4G/5G networks in one place. Some of this follows later in sections 3.2.1 and Yet, the split between these three sections is unclear. Having a discussion about today's Internet path characteristics and the dynamics at one place could be more useful. The text could also better distinguish between what matters to endpoints and considerations relevant only for middleboxes (such as passive monitors). Section 3.3 Path Requirements The statement "to find the bandwidth requirements for a router on the delivery path" may assume that the bottleneck on the path will be routers. Yet, on a path the bottlenecks could also be a link layer device (e.g., an Ethernet Switch, a Wifi access point, etc.). RFC 6077 (specifically Section 3.1.3) also explains that issue. A better wording may be "to find the bandwidth requirements for a delivery path". Section 3.6. Unpredictable Usage Profiles / Section 3.7. Extremely Unpredictable Usage Profiles I am not fully convinced by the distinction between "unpredictable" and "extremely unpredictable". To me, these two sections could be merged and maybe also be shortened. More specifically, Section 3.7 lists a lot of statistics from the past. What is IMHO a bit missing in Section 3.7 are actual operational considerations. For instance, are there any lessons learnt for the future? Note that Section 3.6 has a reasonable conclusion at the end. Section 4. Latency Considerations and Section 4.1. Ultra Low-Latency I am surprised by the definition "ultra low-latency (less than 1 second)", as well as some of the other numbers. For other real-time communication use cases, "ultra low-latency" would probably imply a latency requirement of the order of one millisecond. For instance, isochronous traffic for motion control in industrial networks may require a latency of 1 ms, and such "ultra-low latency" requirements are discussed elsewhere, e.g., in the DetNet WG. The terminology in this section should be better explained to readers dealing with networked systems with much harder latency requirements.


Question: Most applications operating over IP networks and requiring latency this low use the Real-time Transport Protocol (RTP) RFC3550 or WebRTC <del> RFC8825, which uses RTP for the media transport as well as several other protocols necessary for safe operation in browsers. </del> <ins> RFC8825, which uses RTP as its Media Transport Protocol, along with several other protocols necessary for safe operation in browsers. </ins> Worth noting is that many applications for ultra low-latency delivery do not need to scale to more than a few users at a time, which

And a reference should be added for these definitions in the context of video streaming. Section 5.5.2 Head-of-Line Blocking If Head-of-Line Blocking is indeed a relevant operational problem, it would be useful to add a corresponding reference (e.g., with measurements). Section 5.5.3. Wide and Rapid Variation in Path Capacity The statement "As many end devices have moved to wireless connectivity for the final hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have emerged from radio interference and signal strength effects." could be moved to earlier parts of the document. Quite a bit of new computers apparently only have Wifi connectivity and no Ethernet port, i.e., Wifi may just be their default. Also, wireless may not only be used on the last hop, for instance in meshed setups. This may make the problem even harder. Section 6. Evolution of Transport Protocols and Transport Protocol Behaviors I really wonder whether UDP vs. TCP vs. QUIC is actually the relevant distinction. What may actually matter are the transport services provided by the protocol stack (e.g., RFC 8095). I fully agree to a related comment in the INTDIR review. Section 6.1. UDP and Its Behavior UDP is also used for encrypted tunnels (OpenVPN, Wireguard, etc.). Does encrypted tunneling really have no operational impact on streaming apps other than circuit breakers? (I am thinking about 4K streaming over OpenVPN and the like.) Section 6.2. TCP and Its Behavior This text should IMHO be presented and be discussed in TCPM. Personally, I am not convinced that this document is a good place for discussing the long history of TCP congestion control. If the objective of the document is to provide a tutorial, IMHO it would be more useful to briefly explain the state-of-the-art in year 2022. Some further specific comments on TCP congestion control: It is surprising that RFC 5681 is not referenced.793bis has normative statements regarding congestion control, and most stacks are compatible to what is written in 793bis. Several operating systems use CUBIC by default and support standard Reno. Another general good reference for TCP standards is RFC 7414.Does ECN, DCTCP, etc.


Question: Most applications operating over IP networks and requiring latency this low use the Real-time Transport Protocol (RTP) RFC3550 or WebRTC <del> RFC8825, which uses RTP for the media transport as well as several other protocols necessary for safe operation in browsers. </del> <ins> RFC8825, which uses RTP as its Media Transport Protocol, along with several other protocols necessary for safe operation in browsers. </ins> Worth noting is that many applications for ultra low-latency delivery do not need to scale to more than a few users at a time, which

really not matter at all, for instance, if a data center hosts video playout servers? Section 6.3. QUIC and Its Behavior As already noted, the discussion about head-of-line-blocking would really benefit from backing by a reference. Section 7. Streaming Encrypted Media As far as I know, streaming users sometimes use encrypted tunnels such as OpenVPN or WireGuard (or IPsec) to access video content. I may miss something, but it is unclear to me how that fits into the categories presented in Section


Question: 4. <del> Several mechanisms can be employed for discovering the RD, including assuming a default location (e.g. on an Edge Router in a LoWPAN), assigning an anycast address to the RD, using DHCP, or discovering the RD using .well-known/core and hyperlinks as specified in CoRE Link Format RFC6690.  Endpoints that want to contact a Resource Directory (RD) can obtain candidate IP addresses of RD servers dependent on the operational conditions.  It is assumed that the nodes looking for a Resource Directory are connected to a Border Router (6LBR).  Given the various existing network installation procedures, the 6LBR is either connected or disconnected from the Internet and its services like DHCP and DNS.  Two conditions are separately considered: (1) Internet services present, and (2) no Internet services present. When no Internet services are present, the following techniques are used (in random order): Sending a Multicast to [ff02::1]/.well-known/core with ?rt=core.rd*. The receiving RDs will answer the query. The Authoritative Border Router Option (ABRO) present in the Router Advertisements (RA), contains the address of the border router. Assuming that an RD is located at the 6LBR.  Confirmation can be obtained by sending a Unicast to [6LBR]/.well-known/core with ?rt=core.rd*. Address of 6LBR is obtained from ABRO. The 6LBR can send the Resource Directory Address Option (RDAO) during neighbour Discovery containing one or more RD addresses, as explained in The installation manager can decide to preconfigure an ANYCAST address with as destination the interface of the RDs.  Clients send a discovery message to the predefined RD anycast address. Each target network environment in which some of these preconfigured nodes are to be brought up is then configured with a route for this anycast address that leads to an appropriate RD. Instead of using an ANYCAST address, a multicast address can be preconfigured.  All RD directory servers need to configure one of their interfaces with this multicast address. After installation of mDNS on all nodes, mDNS can be queried for the IP-address of RD. When Internet services are present, the techniques cited above are still valid.  Using standard techniques to obtain the addresses of DNS or DHCP servers, the RD can be discovered in the following way: Using a DNSSD query to return the Resource Records (RR) describing </del> <ins> A device coming up may want to find one or more resource directories to make itself known with. The device may be pre-configured to exercise specific mechanisms for finding the resource directory: It may be configured with a specific IP address for the RD.  That IP address may also be an anycast address, allowing the network to forward RD requests to an RD that is topologically close; each target network environment in which some of these preconfigured nodes are to be brought up is then configured with a route for this anycast address that leads to an appropriate RD.  (Instead of using an anycast address, a multicast address can also be preconfigured.  The RD directory servers then need to configure one of their interfaces with this multicast address.) It may be configured with a DNS name for the RD and a resource- record type to look up under this name; it can find a DNS server to perform the lookup using the usual mechanisms for finding DNS servers. It may be configured to use a service discovery mechanism such as DNS-SD RFC6763.  The present specification suggests configuring </ins> the service with name rd._sub._coap._udp, preferably within the <del> domain of the querying nodes. Using DHCPv6 with options to be defined. Assisting the 9 techniques above, requires manual intervention or may be done automatically. Manual management: IP address of RD is present in each node. ANYCAST address or Multicast address of RD is present in each node [see 5,6]. 6LBR receives IP address of RD for distribution via RDAO [see 4]. RD address is configured in DHCP [see 9]. DNS is configured with Resource Record specifying address of RD service [see 8]. Automatic management Multicasting to all nodes to return IP address [see 1]. Querying mDNS to receive IP address [see 7]. 6LBR contains RD service [see 2, 3]. As some of these RD addresses are just (more or less educated) guesses, endpoints MUST make use of any error messages to very strictly rate-limit requests to candidate IP addresses that don't work out.  For example, an ICMP Destination Unreachable message (and, in particular, the port unreachable code for this message) may indicate the lack of a CoAP server on the candidate host, or a CoAP error response code such as 4.05 "Method Not Allowed" may indicate unwillingness of a CoAP server to act as a directory server. </del> <ins> domain of the querying nodes.  [_1] For cases where the device is not specifically configured with a way to find a resource directory, the network may want to provide a suitable default. If the address configuration of the network is performed via SLAAC, this is provided by the RDAO option rdao. If the address configuration of the network is performed via DHCP, this could be provided via a DHCP option (no such option is defined at the time of writing). Finally, if neither the device nor the network offer any specific configuration, the device may want to employ heuristics to find a suitable resource directory. The present specification does not fully define these heuristics, but suggests a number of candidates: In a 6LoWPAN, just assume the Edge Router (6LBR) can act as a resource directory (using the ABRO option to find that RFC6775). Confirmation can be obtained by sending a Unicast to coap://[6LBR]/.well-known/core?rt=core.rd*`. In a network that supports multicast well, discovering the RD using a multicast query for /.well-known/core as specified in CoRE Link Format RFC6690: Sending a Multicast GET to "coap://[ff02::1]/.well-known/core?rt=core.rd*".  RDs within the multicast scope will answer the query. As some of the RD addresses obtained by the methods listed here are just (more or less educated) guesses, endpoints MUST make use of any error messages to very strictly rate-limit requests to candidate IP addresses that don't work out.  For example, an ICMP Destination Unreachable message (and, in particular, the port unreachable code for this message) may indicate the lack of a CoAP server on the candidate host, or a CoAP error response code such as 4.05 "Method Not Allowed" may indicate unwillingness of a CoAP server to act as a directory server. </ins> 4.1.

... as promised for yesterday (oops)
ad "what is sub": it's DNS-SD's syntax for subtypes (RFC6763 Section 7.1). Might also be URL ("Subtype strings are not required to begin with an underscore, though they often do").
Looks good to me.
There are several ways specified for finding a host serving an RD: static (unicast or anycast, addresses or DNS? could contain full RD path (as in LWM2M)?) various neighbor discovery derived RDAO the border router (ABRO) "other ND options that happen to point to servers (such as RDNSS)" might-be-defined DHCPv6 options multicast (all-coap-nodes + .well-known/core; serves the path by design) There is an open issue to describe how this can be used with DNS-SD (), and it came up 2017-04-07 that discovery via mDNS by those mechanisms might be possible but is not advisable. Can we give a set of discovery options that should be supported by all general-purpose clients and servers to avoid fragmentation where one vendor's clients expect an RDAO while the other vendor's server relies on clients doing a multicast? Can we say anything about which options are recommended to use, and which are rather to be viewed as shortcuts in extremely constrained cases? Using RDNSS would be a candidate for such a statement. Maybe those cases are better described as "explicitly configured to use whichever RDNSS is announced", so this is something that's better than static configuration but still not to be expected from a generic client.
The new section 4 introduced in URL takes care of this.


Question: If the EAP-TLS peer authenticates successfully, the EAP-TLS server MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used.  The message <del> flow ends with the EAP-TLS server sending an EAP-Success message. </del> <ins> flow ends with a protected success indication from the EAP-TLS server, follwed by an EAP-Response packet of EAP-Type=EAP-TLS and no data from the EAP-TLS peer, follwed by EAP-Success from the server. </ins> If the EAP-TLS server authenticates successfully, the EAP-TLS peer MUST send an EAP-Response message with EAP-Type=EAP-TLS containing

Hi! I performed a second AD review on draft-ietf-emu-eap-tls13. This time on -18. Thank you to the authors, the responsible co-chair, and the WG for all of the work to redesign the -13 protocol in response to the initial IESG review in December 2020. My review feedback consists of my own minimal additional comments and highlights of where previously stated IESG ballot items do not appear to be responded to or addressed. All items appear to be minor. ** Section 2.4. Previously, this text referenced TLS 1.3 or higher necessitating more ambiguous reference to version numbers. However, now the text only notes TLS 1.3. OLD When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP- TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange algorithms, extensions, etc.) for the TLS version used. For TLS 1.3 the compliance requirements are defined in Section 9 of [RFC8446]. NEW When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP-TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange algorithms, extensions, etc.) defined in Section 9 of [RFC8446]. ==[ COMMENT (Ben Kaduk) Section 2.1.4 The two paragraphs below replaces the corresponding paragraphs in Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3 or higher. The other paragraphs in Section 2.1.3 of [RFC5216] still apply with the exception that SessionID is deprecated. If the EAP-TLS peer authenticates successfully, the EAP-TLS server MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used. The message flow ends with the EAP-TLS server sending an EAP-Success message.


Question: If the EAP-TLS peer authenticates successfully, the EAP-TLS server MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used.  The message <del> flow ends with the EAP-TLS server sending an EAP-Success message. </del> <ins> flow ends with a protected success indication from the EAP-TLS server, follwed by an EAP-Response packet of EAP-Type=EAP-TLS and no data from the EAP-TLS peer, follwed by EAP-Success from the server. </ins> If the EAP-TLS server authenticates successfully, the EAP-TLS peer MUST send an EAP-Response message with EAP-Type=EAP-TLS containing

If the EAP-TLS server authenticates successfully, the EAP-TLS peer MUST send an EAP-Response message with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used. Just to walk through the various scenarios here; if the last message of the TLS handshake for a given TLS version is sent by the TLS client, that will go in an EAP-Response, so the server is then able to send EAP-Success directly. On the other hand, if the last TLS handshake message is sent by the server, that will have to go in an EAP-TLS EAP-Request, and so the peer will have to send an empty EAP-TLS response in order for the server to be able to wend EAP-Success? Do we need to have any text here to handle that empty EAP-TLS Eap-Request case? ==[ COMMENT(Alvaro Retana) Is the intention of the Appendix to provide additional formal updates to rfc5216? That is what it looks like to me, but there's no reference to it from the main text. Please either reference the Appendix when talking about some of the other updates (if appropriate) or specifically include the text somewhere more prominent. [Roman] As proposed above, please provide some forward reference. ==[ COMMENT (Éric Vyncke) I find "This section updates Section 2.1.1 of [RFC5216]." a little ambiguous as it the 'updated section' is not identified clearly. I.e., as the sections in RFC 5216 are not too long, why not simply providing whole new sections ? [Roman] I'd propose a simple fix by using (approximate phrases such as) either: This section updates Section xxx of [RFC5216] by amending it with the following text. (for the cases where the intent is to keep the existing text in rfc5216 but add this new text) This section updates Section xxx of [RFC5216] by replacing it with the following text. (for the cases where the intent is to replace an entire section in rfc5216) ==[ COMMENT (Éric Vyncke) None of us are native English speaker, but "e.g." as "i.e."


Question: If the EAP-TLS peer authenticates successfully, the EAP-TLS server MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used.  The message <del> flow ends with the EAP-TLS server sending an EAP-Success message. </del> <ins> flow ends with a protected success indication from the EAP-TLS server, follwed by an EAP-Response packet of EAP-Type=EAP-TLS and no data from the EAP-TLS peer, follwed by EAP-Success from the server. </ins> If the EAP-TLS server authenticates successfully, the EAP-TLS peer MUST send an EAP-Response message with EAP-Type=EAP-TLS containing

are usually followed by a comma while "but" has usually no comma before ;-) [Roman] A simple s/e.g./e.g.,/ and s/i.e./i.e.,/ would catch this. Regards, Roman
==[ COMMENT (Éric Vyncke) None of us are native English speaker, but "e.g." as "i.e." are usually followed by a comma while "but" has usually no comma before ;-) [Roman] A simple s/e.g./e.g.,/ and s/i.e./i.e.,/ would catch this. Eric is correct that US english i.e. and e.g. is usually followed by a comma. I corrected this in d9f5028 I also run a word spell check on the document. Word does not suggest removing any comma after "but" but rather insert an additional comma after a but. I think this can be left to the RFC editor. The word spell check caught two other grammar errors (s after plural, no s after singular) RFC 8446 does not use capitalization on post-handshake as that is just a name for a set of messages. I corrected these things in
I Made a new PR
Made a commit with NEW When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP-TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange algorithms, extensions, etc.) defined in Section 9 of [RFC8446].
Section 2.1.4 Changed the text to: The message flow ends with a protected success indication from the EAP-TLS server, follwed by an EAP-Response packet of EAP-Type=EAP-TLS and no data from the EAP-TLS peer, follwed by EAP-Success from the server.
I added a forward reference to the appendix in the introduction
NAME looks like you have got everything covered? are there any comments from Roman which still need to be addressed? should we submit a new version and ask for IETF last call?
I have tried to do everything. Problem with the updates thing.


Question: If the EAP-TLS peer authenticates successfully, the EAP-TLS server MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used.  The message <del> flow ends with the EAP-TLS server sending an EAP-Success message. </del> <ins> flow ends with a protected success indication from the EAP-TLS server, follwed by an EAP-Response packet of EAP-Type=EAP-TLS and no data from the EAP-TLS peer, follwed by EAP-Success from the server. </ins> If the EAP-TLS server authenticates successfully, the EAP-TLS peer MUST send an EAP-Response message with EAP-Type=EAP-TLS containing

The replace or amend strategy does not really work.... [Roman] I'd propose a simple fix by using (approximate phrases such as) either: This section updates Section xxx of [RFC5216] by amending it with the following text. (for the cases where the intent is to keep the existing text in rfc5216 but add this new text) This section updates Section xxx of [RFC5216] by replacing it with the following text. (for the cases where the intent is to replace an entire section in rfc5216)
NAME We should likely not do to much changes. Maybe we can write something like Amends with the following text. TLS 1.2 specific details in RFC 5216 are replaced. Requirement in the new takes precedence over requirements in the old text.
This review was addressed in earlier submissions. closing


Question: all streams other than the first will be marked as bundle-only. This policy aims to minimize candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy <del> endpoints.  When acting as answerer, if there if no bundle group in the offer, the implementation will reject all but the first m= section. </del> <ins> endpoints.  When acting as answerer, the implementation will reject any m= sections other than the first m= section, unless they are in the same bundle group as that m= section. </ins> As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default bundle policy MUST

NAME NAME PTAL
From Berlin: "A clarification to that rule was found when an offer is received with some m= lines bundled and some not; you accept all m= lines that are possible to bundle with the first m= line. "
I think we'll also have to update section 5.3.1 (Initial Answers) where it lists conditions for rejecting an m= section. Also, do we need to make similar modifications for the "balanced" bundle policy? LG with nits


Question: Run by the client when processing the server response in the issuance phase of the protocol.  The output of this function is an array of "RedemptionToken" objects that are unlinkable from the server's <del> computation in "PP_Issue". </del> <ins> computation in "Issue". </ins> Inputs:

These functions do not need the "PP_" namespace prefix as it's implied from the specification. I also removed underscores in favor of normal camel case notation.


Question: between a specific local address and a specific peer address, where an address is the two-tuple of IP address and port. <del> Path validation tests that packets can be both sent to (PATH_CHALLENGE) and received from (PATH_RESPONSE) a peer on the path.  Importantly, it validates that the packets received from the migrating endpoint do not carry a spoofed source address. </del> <ins> Path validation tests that packets sent on a path to a peer are received by that peer.  Path validation is used to ensure that packets received from a migrating peer do not carry a spoofed source address. Path validation does not validate that a peer can send in the return direction.  The peer performs independent validation of the return path. </ins> Path validation can be used at any time by either endpoint.  For instance, an endpoint might check that a peer is still in possession

The original design for path validation attempted to validate return reachability by requiring that PATHRESPONSE followed the same path as PATHCHALLENGE. We removed that long ago, but the text retained echoes of that choice.
Currently, does not specify which path a PATHRESPONSE needs to be sent over. That was somewhat surprising to me, as I had expected it to be scoped to the path that PATHCHALLENGE was received on. If it isn't, could we add a sentence to the Path Validation Responses subsection to explicitly state that a PATH_RESPONSE is not scoped to a given path (and ideally explaining why it isn't)?
So I thought we were really crisp about this, but we were not. PATHRESPONSE does not need to follow the path on which PATHCHALLENGE was received. We're clear about this when it comes to preferred address handling, but there is some vestigial text that contradicts this. That should be fixed.
For the record, I personally believe that adequately resolves this issue while remaining purely editorial.
Thanks for being so prompt David. I will leave this for a bit to allow others a chance to spot errors, but I plan to merge this before we publish -30 (real soon now, I hope).
Yes, the requirement was removed but the inverse statement was never explicitly added. corrects that.
Thanks for writing this up, tiny wording suggestions, but looking great! Thanks for writing this up, I think this adequately resolves my concerns from .


Question: 2.4.5. <del> The "count" function extension provides a way to obtain the number of nodes in a nodelist and make that available for further processing in the filter expression: </del> <ins> The "count()" function extension provides a way to obtain the number of nodes in a nodelist and make that available for further processing in the filter expression: </ins> Its only argument is a nodelist.  The result is a value, an unsigned integer, that gives the number of nodes in the nodelist.  Note that

Use parentheses as an indication that something is a function. Also, don't confuse the reader by alluding to potential future alternatives to value(). Reviewers: is this an improvement? It's a draft PR for now until we decide the change is worthwhile.
I think we'll need to explain the () notation, which should be familiar to C programmers but not necessarily to people who grew up on other languages. I also think we have a few more examples that point to hypothetical functions, such as , , .
I don't think there's a great point at which to explain that notation and, based on your observation, I'm going off the idea.
NAME Let's see how pans out before taking the current PR any further. Once I remove the function parentheses, the two PRs are changing the same text.
would be the place.
NAME As you suggested, I introduced this in 1.1, but near the start since it's notation rather than terminology. I did a regexp search to find and fix the remaining examples (your list was complete). In doing so, I found the strange markup and removed the backticks since there was no good reason for them.
We could do the fun() explanation and completeness search in a separate PR.


Question: This document uses the following terms: Appraisal Policy for Evidence: A set of rules that direct how a <del> verifier evaluates the validity of information about an Attester. </del> <ins> Verifier evaluates the validity of information about an Attester. </ins> Compare /security policy/ in [RFC4949]. Appraisal Policy for Attestation Result: A set of rules that <del> direct how a Relying Party evaluates the validity of information about an Attester.  Compare /security policy/ in [RFC4949]. </del> <ins> direct how a Relying Party uses the evaluation results about an Attester generated by the Verifiers.  Compare /security policy/ in [RFC4949]. </ins> Attestation Result: The evaluation results generated by a Verifier, typically including information about an Attester, where

When comparing the term 'Appraisal Policy for Evidence' and 'Appraisal Policy for Attestation Result', they are both saying 'evaluates the validity of information about an Attester'. This makes me feel Verifier and Relying Party are doing the same things and they are redundant. I think it's more appropriate to say that the Relying Party evaluates the evaluation results generated by the Verifiers.


Question: As QUIC is a general purpose transport protocol, there are no requirements that servers use a particular UDP port for QUIC.  For applications with a fallback to TCP that do not already have an <del> alternate mapping to UDP, the registration (if necessary) and use of the UDP port number corresponding to the TCP port already registered for the application is RECOMMENDED.  For example, the default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. </del> <ins> alternate mapping to UDP, usually the registration (if necessary) and use of the UDP port number corresponding to the TCP port already registered for the application is appropriate.  For example, the default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. </ins> Applications could define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example,

Issue: “and use of the UDP port number corresponding to the TCP port already registered for the application is RECOMMENDED”. I agree with the intent, but here an RFC2119 keyword is used, but is this intended, and can this please cite the RFC that says this rather than just stating this.
Similarly noted in
PR removes normative language and says "usually ... appropriate" instead. Is that okay? Or should the wording be stronger?


Question: 13.1.3. <del> A Remove proposal requests that the member with LeafNodeRef "removed" be removed from the group. </del> <ins> A Remove proposal requests that the member with the leaf index "removed" be removed from the group. </ins> A member of the group applies a Remove message by taking the following steps:

This seems to be a layer of indirection that doesn't add any value to implementation.
The Credentials section claims there is an epoch id field in key packages. I don't think that actually exists. My apologies if this is a duplicate issue.
Addressed in but may need to be pulled out depending on the fate of that PR
contains all of the Proposals that were previously sent within the same epoch. This seems unnecessary, since all members should have them anyway. The list of in the actual message should be enough for members to parse and validate a message. We should discuss if we can de-duplicate this, since the list of Proposals might be quite long.
The current definition of is as follows; Maybe this issue is obsolete?
Seems it is now obsolete indeed.
I don't have a strong opinion on this question, but this change seems sensible to me. The use of LeafNodeRef requires either (a) a linear scan through the tree, which is time-expensive in large trees, or (b) keeping an index that maps LeafNodeRef values to indices, which is storage-intensive in large trees. IIRC, the change to LeafNodeRef was made in the context of NAME work to make the tree description less tied to the array representation. In general, that is the right thing to do, and it's good that we did it. But we still have leaf indices anyway, for . Since we still have the concept, we might as well use it where it makes sense. And it certainly seems to me like and make sense, since they are internal to the protocol. In case folks are worried about the application-facing API -- MLS stacks can certainly be more intelligent, e.g., exposing or or . But they can do that regardless of this PR.


Question: extension, the endpoint MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. <del> 4.4. </del> <ins> 4.4.4. </ins> The DATAGRAM capsule (see iana-types for the value of the capsule type) allows an endpoint to send a datagram frame over an HTTP

Had offline conversation with Lucas, conclusion was that this is good enough to merge to allow interop - we'll have plenty of time to figure out details in subsequent issues and PRs.


Question: sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 (as does the two byte sequence 40 25). <del> Versions (versions) and error codes (error-codes) are described using integers, but do not use this encoding. </del> <ins> Versions (versions) and packet numbers sent in the header (packet- encoding) are described using integers, but do not use this encoding. </ins> 17.

Error codes do use varints, but packet numbers (in the header) don't.


Question: in the credential field of the KeyPackage objects in the leaves of the tree (including the InitKeys used to add new members). <ins> To disambiguate different signatures used in MLS, each signed value is prefixed by a label as shown below: Here, the functions "Signature.Sign" and "Signature.Verify" are defined by the signature algorithm. </ins> The ciphersuites are defined in section mls-ciphersuites. 6.2.

Signatures as specified in the MLS protocol document are ambiguous, in the sense that signatures produced for one purpose in the protocol can be (maliciously) used in a different place of the protocol. Indeed, we found that for example, a can have the same serialization as , which proves that one signature could be accepted for different structures. The collisions we have found so far are quite artificial, so it is not super clear how to exploit this, but at least it makes it impossible to have provable security. The solution is pretty simple, we simply prefix each signed value with a label, in a fashion similar to . That way, when calling you can give the structure name in the argument.
Something that is still bothering me is the structure: struct { select (URL) { case member: GroupContext context; case preconfigured: case newmember: struct{}; } WireFormat wireformat; opaque groupid; uint64 epoch; Sender sender; opaque authenticateddata; ContentType contenttype; select (MLSPlaintextTBS.contenttype) { case application: opaque applicationdata; case proposal: Proposal proposal; case commit: Commit commit; } } MLSPlaintextTBS; Since the first is done on a field defined after it, this structure is not parsable. We could say that's not a problem since we only need to serialize it, but for security purposes I would recommend to put it at the end, like this: struct { WireFormat wireformat; opaque groupid; uint64 epoch; Sender sender; opaque authenticateddata; ContentType contenttype; select (MLSPlaintextTBS.contenttype) { case application: opaque applicationdata; case proposal: Proposal proposal; case commit: Commit commit; } select (URL) { case member: GroupContext context; case preconfigured: case newmember: struct{}; } } MLSPlaintextTBS; What do you think about it?
Nice one! Crafting collisions is probably not straightforward, but eliminating the the risk altogether is the way to go.
It is actually quite easy to craft collisions, I made a script do find them: URL (I wanted to check whether there was accidentally a way do disambiguate the structures)
Introduced in .


Question: in the credential field of the KeyPackage objects in the leaves of the tree (including the InitKeys used to add new members). <ins> To disambiguate different signatures used in MLS, each signed value is prefixed by a label as shown below: Here, the functions "Signature.Sign" and "Signature.Verify" are defined by the signature algorithm. </ins> The ciphersuites are defined in section mls-ciphersuites. 6.2.

s currently have two usages in the spec: Pre-published key packages that you can download and put in a leaf when adding a new member leaf node content that you update when doing a full Currently, things have been designed to use only one structure for both uses, leading to some weirdness such as: and are useful in the usage 1, but are parameters of the group in usage 2. is a good name in usage 1, but would better be named in usage 2. some data is important in usage 2 and have no meaning in usage 1, hence they were designed as "mandatory-when-updating extensions" (such as , and we were also discussing about adding the in to help prevent cross-group attacks) How about using different structures for these? // Essentially identical to KeyPackage struct { ProtocolVersion version; CipherSuite ciphersuite; HPKEPublicKey hpkeinitkey; opaque endpointid; Credential credential; Extension extensions; opaque signature; } PrePublishedKeyPackage; struct { HPKEPublicKey hpkekey; opaque endpointid; Credential credential; opaque parenthash; opaque groupid; Extension extensions; opaque signature; } LeafNodeContent; enum { reserved(0), prepublishedkeypackage(1), leafnodecontent(2), (255) } LeafNodeType; struct LeafNode { // This is not included in the signature, but with the "unambiguous signature" PR that's not a problem LeafNodeType type; select(URL) { case prepublishedkeypackage: PrePublishedKeyPackage data; case leafnode_content: LeafNodeContent data; } } What would you think about refactoring like this?
If we're doing this, I'd suggest including a dedicated public key to encrypt Welcome messages to for the . NAME suggested this at some point. It gives us better FS guarantees, because the receiver of the can delete the corresponding private key immediately after decryption, while they might have to keep the other key around for a bit until they can actually issue an update. This might also help clarify .
Ties into as well because is an example of an extension that is required and should be a field instead
NAME one concern I have is how is that field in created?
When sending a full , the participant includes a new in the (it replaces the field).


Question: in the credential field of the KeyPackage objects in the leaves of the tree (including the InitKeys used to add new members). <ins> To disambiguate different signatures used in MLS, each signed value is prefixed by a label as shown below: Here, the functions "Signature.Sign" and "Signature.Verify" are defined by the signature algorithm. </ins> The ciphersuites are defined in section mls-ciphersuites. 6.2.

It computes the signature with where: corresponds to all the fields of except (the usual thing) comes from
What about the scenario where Alice pulls down Bob's key package to add him to the group? In that case Alice can't do the conversion between formats on Bob's behalf.
Alice don't have to do the conversion, this is why either contain a (when adding someone to the group) or a (when updating your own key package).
Ah somehow I missed that part in your original post. Makes sense
I like this general direction. It solves a few things. Instead of having leaf nodes contain either a prepublished thing or a normal leaf node, how about having the prepublished thing wrap the leaf node thing? As a bonus, we get separation between the key pair used for Welcome encryption and the key pair that goes in the leaf for TreeKEM. Then when Alice adds Bob, she extracts his LeafNodeContent and sends that in the Add. That doesn't let the other members of the group verify that Alice did the right thing w.r.t. expiry, but I'm not heartbroken about that. We might also be able to remove the extensions field from the outer (KeyPackage) wrapping if we turn the extension into KeyPackage field. I expect we probably need leaf extensions, but would be open to making into a field.
Why not keep sending the KeyPackage in the Add? That wouldn't cost much and would allow everyone to validate the lifetime. Note, that the lifetime is crucial in achieving PCS for pre-published key material. If I compromise Bob and get hold of the private key material of a bunch of his KeyPackages, I can add "Bob" to any group I want as long as the Credential inside the LeafNodeContent remains valid and Bob doesn't revoke the LeafNodeContent somehow. Also, we'll have to do this if we want to enable any member to send the Welcome message as you proposed here: URL
I agree that including inside is quite clean, but something is bothering me with this approach: I'd like that the is signed by the participant occupying that leaf, to protect against cross-group attacks. In the first message of this issue I did this by including in , but in fact we don't need to store it in the leaf, we just need to include it in the .


Question: in the credential field of the KeyPackage objects in the leaves of the tree (including the InitKeys used to add new members). <ins> To disambiguate different signatures used in MLS, each signed value is prefixed by a label as shown below: Here, the functions "Signature.Sign" and "Signature.Verify" are defined by the signature algorithm. </ins> The ciphersuites are defined in section mls-ciphersuites. 6.2.

In any case, if we want to include in the signature, we need a way to differentiate between leaves that triggered a commit and the ones that are "fresh". And for that I think using a tagged-union struct is the cleanest way to do it.
It always feels a bit lazy to use an extension (and implementations have to be careful to check for their presence), but we could use a extension in the same way that we use a extension. You will find both of them only on LeafContents that were updated at least once. Another result of including GroupId in the KeyPackage is that the signature will explicitly sign the and I'm not sure if that doesn't completely destroy any deniability guarantees we can still get from MLS.
I don't think there's really a good way to get the into the leaf. Because of prepublication, it would have to be optional, but in order to prevent attacks, you need rules to decide whether it's required in a given situation. It seems like the best you can do is basically TOFU: When you first get the tree, you can't validate whether the groupid should be in a given leaf or not Once you're a member, you require that groupid is sent in Update and UpdatePath.leafkey_package I could live with a solution of that character, but given it's a bit complex, might prefer to leave it out unless we get a useful property from it. NAME - Re: Sending KeyPackage in Add - Yep, that makes sense. So you would send KeyPackage in Add, and LeafNode in Update.
I tried to worked through what would be necessary to implement this. It looks like it would require some fairly invasive changes to be made to rationalize the document's structure before making this change. But those changes should probably be made anyway.


Question: in the credential field of the KeyPackage objects in the leaves of the tree (including the InitKeys used to add new members). <ins> To disambiguate different signatures used in MLS, each signed value is prefixed by a label as shown below: Here, the functions "Signature.Sign" and "Signature.Verify" are defined by the signature algorithm. </ins> The ciphersuites are defined in section mls-ciphersuites. 6.2.

Proposal: Preparatory PR: Rationalize layout Move "Cryptograhic Objects" to before "Ratchet Trees" Update "Ratchet Tree Nodes" to define ParentNode and LeafNode structs, with LeafNode initially just equal to KeyPackage Move subsections of "Key Packages" to under "Ratchet Trees" Parent Hash Tree Hashes Update Paths Move Group State to its own top-level section Main PR: Change LeafNode to have the required content: HPKE key for TreeKEM Credential Parent hash Capabilities Extensions Signature Change KeyPackage to refer to LeafNode for internals, plus: HPKE key for Welcome Lifetime Extensions Signature Add continues to send KeyPackage Update and Commit send LeafNode instead of KeyPackage Remove and Sender refer to LeafNodeRef instead of KeyPackageRef We should probably do the preparatory PR regardless of this issue.
Discussion on working call: General agreement on the approach Should sign group_id when possible Include in TBS if we at least have a flag for pre-published / in-group Or we can store it Or we could have independent structs for pre-published / in-group leaves Do we need extensions at both levels? Capabilities / lifetime should probably be promoted to fields
From what I can see, there is no reason not to sign the context in the case of an external init. I'm not sure why it got taken out, but while implementing external inits, verification went through even when including the context.
As I commented in , it's not even clear that we need this context any more for members any more, given for MLSPlaintext and the AEAD of MLSCiphertext. So I would propose we just remove the context added to MLSPlaintextTBS altogether. NAME IIRC you were the one that proposed adding the context. WDYT?
This was fixed in
Here's the Weekly Digest for : - - Last week 9 issues were created. Of these, 6 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :heart: , by :heart: , by :heart: , by :speaker: , by It received 2 comments. - - Last week, 13 pull requests were created, updated or merged. Last week, 3 pull requests were updated.


Question: in the credential field of the KeyPackage objects in the leaves of the tree (including the InitKeys used to add new members). <ins> To disambiguate different signatures used in MLS, each signed value is prefixed by a label as shown below: Here, the functions "Signature.Sign" and "Signature.Verify" are defined by the signature algorithm. </ins> The ciphersuites are defined in section mls-ciphersuites. 6.2.

:yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 10 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 38 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .*


Question: mapping for an overiew.  A comparison between HTTP/2 and HTTP/3 frames is provided in h2-frames. <ins> Certain frames can only occur as the first frame of a particular stream type; these are indicated in stream-frame-mapping with a (1). Specific guidance is provided in the relevant section. </ins> 4.1. All frames have the following format:

This is my stab at adding the indication discussed in .
Lgtm. An minor Improvement might be to highlight in the new sentence that "specific guidance is provided in the relevant section" but that might be obvious. I'm happy without anything further.


Question: 4. <del> CAPSULE allows reliably sending request-related information end-to- </del> <ins> This specification introduces the Capsule Protocol.  The Capsule Protocol is a sequence of type-length-value tuples that allows endpoints to reliably communicate request-related information end-to- </ins> end, even in the presence of HTTP intermediaries. <del> CAPSULE is an HTTP/3 Frame (as opposed to a QUIC frame) which SHALL only be sent in client-initiated bidirectional streams. Intermediaries forward received CAPSULE frames on the same stream where it would forward DATA frames.  Each Capsule Type determines whether it is opaque or transparent to intermediaries: opaque capsules are forwarded unmodified while transparent ones can be parsed, added, or removed by intermediaries. </del> <ins> 4.1. This specification defines the "data stream" of an HTTP request as the bidirectional stream of bytes that follow the headers in both directions.  In HTTP/1.x, the data stream consists of all bytes on the connection that follow the blank line that concludes either the request header section, or the 2xx (Successful) response header section.  In HTTP/2 and HTTP/3, the data stream of a given HTTP request consists of all bytes sent in DATA frames with the corresponding stream ID.  The concept of a data stream is particularly relevant for methods such as CONNECT where there is no HTTP message content after the headers. Definitions of new HTTP Methods or of new HTTP Upgrade Tokens can state that their data stream uses the Capsule Protocol.  If they do so, that means that the contents of their data stream uses the following format (using the notation from the "Notational Conventions" section of QUIC): A variable-length integer indicating the Type of the capsule. Endpoints that receive a capsule with an unknown Capsule Type MUST silently skip over that capsule. The length of the Capsule Value field following this field, encoded as a variable-length integer.  Note that this field can have a value of zero. The payload of this capsule.  Its semantics are determined by the value of the Capsule Type field. 4.2. </ins> <del> This specification of CAPSULE currently uses HTTP/3 frame type 0xffcab5.  If this document is approved, a lower number will be requested from IANA. </del> <ins> If the definition of an HTTP Method or HTTP Upgrade Token states that it uses the capsule protocol, its implementations MUST follow the following requirements: </ins> <del> The Type and Length fields follows the definition of HTTP/3 frames from H3.  The payload consists of: </del> <ins> A server MUST NOT send any Transfer-Encoding or Content-Length header fields in a 2xx (Successful) response.  If a client receives a Content-Length or Transfer-Encoding header fields in a successful response, it MUST treat that response as malformed. </ins> <del> The type of this capsule. </del> <ins> A request message does not have content. </ins> <del> Data whose semantics depends on the Capsule Type. </del> <ins> A successful response message does not have content. Responses are not cacheable. 4.3. Intermediaries MUST operate in one of the two following modes: In this mode, the intermediary forwards the data stream between two associated streams without any modification of the data stream. In this mode, the intermediary terminates the data stream and parses all Capsule Type and Capsule Length fields it receives. Each Capsule Type determines whether it is opaque or transparent to intermediaries in participant mode: opaque capsules are forwarded unmodified while transparent ones can be parsed, added, or removed by intermediaries.  Intermediaries MAY modify the contents of the Capsule Data field of transparent capsule types. </ins> Unless otherwise specified, all Capsule Types are defined as opaque to intermediaries.  Intermediaries MUST forward all received opaque


Question: registration if it were not to be used in lookup or attributes, but would make a bad parameter for lookup, because a resource lookup with an "if" query parameter could ambiguously filter by the registered <del> endpoint property or the RFC6690 target attribute).  It is expected that the registry will receive between 5 and 50 registrations in total over the next years. </del> <ins> endpoint property or the RFC6690 target attribute). </ins> 9.3.1.

Something around "whether many registrations are expected over time" is supposed to be said according to BCP26, but it seems this belongs in the shepherd write-up, where it is now being added. To be merged right away.


Question: For each stored security context, the first time after boot the server receives an OSCORE request, the server uses the Repeat option I-D.amsuess-core-repeat-request-tag to get a request with <del> verifiable freshness and uses that to synchronize the replay window.  If the server can verify the fresh request, the Partial IV in the fresh request is set as the lower limit of the replay </del> <ins> verifiable freshness. The Request option in the server's response MUST be encrypted, and the server MUST NOT use the same nonce as the request in its reply. If the server can verify a second request as fresh, the Partial IV of the second request is set as the lower limit of the replay </ins> window. 6.5.3.

This prescribes explicitly one of the possible ways that the response is sent, and states the (hopefully) obvious about accepting new requests. The alternative to "MUST NOT be encrypted" would be "MUST be encrypted and MUST carry an explicit IV"; even both would work, but clients need to know what they need to be prepared for. I'd be fine with either of the two (or three) versions of the request encryption, but not stating anything might result in incompatible implementations where one only works this and one only works that way. Being explicit about (to us) obvious things like not responding with an implied IV or not accepting Repeat as Class U (or in an unencrypted request that might then clear the way for any replays) might not be necessary from a specification point of view, but could avoid implementation errors I see very vividly before my inner eye.
Come to think of it (from the considerations in URL), we have to go the other way and say that the response "MUST be encrypted, and MUST use an explicit partial IV". As we want to use this for HTTP too, this is by far the easier option; otherwise, we'd have to additionally specify how the option is transported in HTTP, so a HC proxy can convert it, and then the HC proxy would need to know whether it's transporting OSCORE (so it'd forward the Repeat option for the HTTP client to include it in a new encrypted request) or whether it's working for an OSCORE-unaware client that would not be equipped to answer the Repeat challenge (so it'd repeat the known fresh (because HTTP) request with a Repeat option by itself without bothering the client).
Did I understand right, that you take back the proposal in the PR? Partial IV generated by the server is allowed in any response. With the resolution of issue : "if Partial IV present in the message -> use that Partial IV" Hence the replay draft can specify that replay syncing MUST use the server generated PIV, in which case it will be encrypted. I probably missed the issue?
Yes; I'll still need to update the PR to say the desired. We don't need to change anything about mechanism, but we should be explicit that the server MUST reply with an encrypted Repeat and a generated partial IV.
Sorry, still not clear: OSCORE now allows the use of server-generated Partial IV. The processing for Repeat is defined in the RRT-draft.


Question: For each stored security context, the first time after boot the server receives an OSCORE request, the server uses the Repeat option I-D.amsuess-core-repeat-request-tag to get a request with <del> verifiable freshness and uses that to synchronize the replay window.  If the server can verify the fresh request, the Partial IV in the fresh request is set as the lower limit of the replay </del> <ins> verifiable freshness. The Request option in the server's response MUST be encrypted, and the server MUST NOT use the same nonce as the request in its reply. If the server can verify a second request as fresh, the Partial IV of the second request is set as the lower limit of the replay </ins> window. 6.5.3.

Why does anything else need to change in the OSCORE draft?
Wrote the promised changes as it's much easier to talk with concrete text; the PR is now updated as 81d47927. This doesn't change any mechanism (at least not in implementations that are based on the current text and written in full awareness of all the relevant considerations). It is just a text change that prescribes what will be obvious to some implementors but not to others. (Especially since it's not so obvious as that I would have gotten it right in the first attempt.)
(This issue takes some context from issue ). The current draft states that replay protection violation triggers a 5.03 with Max-Age 0 (Section 6.4). While this is a practical solution to issue (which is not mitigated by encrypting the code because FETCH is still safe), it could still be caught by a proxy that'd try to be smart about it (and would, AFAICT, be within its rights). I suggest that the response code be 4.01 Unauthorized with Max-Age=0. The semantics of Unauthorized are "SHOULD NOT repeat the request without first improving its authentication status to the server", and while it's a bit of a stretch to say that increasing the sequence number is sufficient to improve the authentication status, the Max-Age gives a good hint ("Come on, try again right away, don't look for other keys"), and clients can use the presence of the Max-Age option as a discriminator to tell "Sorry, no such context" apart from "Retry with a new seqno".
We also just identified this response code as not appropriate. The proposal is good, unless it results in overloading the semantics of Max-Age=0. There is already at least one requirement when Max-Age has to be zero: RFC7252, Section 5.6.1: "If an origin server wishes to prevent caching, it MUST explicitly include a Max-Age Option with a value of zero seconds." Is there a setting where the the server would not want the response 4.01 to be cached even though it is not a replay? (Obviously we have to differentiate between Inner and Outer 4.01, but is that enough?)
I don't know.


Question: For each stored security context, the first time after boot the server receives an OSCORE request, the server uses the Repeat option I-D.amsuess-core-repeat-request-tag to get a request with <del> verifiable freshness and uses that to synchronize the replay window.  If the server can verify the fresh request, the Partial IV in the fresh request is set as the lower limit of the replay </del> <ins> verifiable freshness. The Request option in the server's response MUST be encrypted, and the server MUST NOT use the same nonce as the request in its reply. If the server can verify a second request as fresh, the Partial IV of the second request is set as the lower limit of the replay </ins> window. 6.5.3.

I briefly thought about using an Echo here, but an HTTP proxy would react to that as a CoAP proxy would to 5.03,Max-Age=0. (See comments 2ff). I did give that some thought, and considering the Echo option thought about whether the server should just reply with an encrypted ,Max-Age=0 (or Echo=short). I decided against suggesting that because responding to a possibly fraudulent message with an owned partial IV means that any adversary that has one valid-but-used message can thus drive any server into partial-IV exhaustion.
By the way, just FYI, that Max-Age=0 with 5.03 means "service unavailable, retry in 0 seconds", which is wrong (and not what we want). (see: URL)
The current text where there MAY be a Max-Age of 0 both on "4.01, Security context not found" and on "4.01, Security context not found" means that a client can not know any more which is the case (and it should not look into the message). I see the reason for the MAY set Max-Age for most error cases in , but a client needs to keep those apart (otherwise it'd need to so something like try 3 times with a new PIV, and if the server still responds the same, assume that it doesn't know the KID). I suggest that for those two responses, the Max-Age values are enforced as "MUST NOT set a Max-Age option" and "MUST set the Max-Age option to 0", or find any other discriminator, but an implementation should be able to tell them apart.
Granted, with the current setup of POST and FETCH there are much fewer cases where replay protection errors can happen (they'd only legally happen under particular package loss situations when starting an observation via a proxy that does not support observation but does do optimizations for safe requests), but I still think that there'd be more clarity if there were a discriminant between the two error cases.
The document, as of now, specifies that Partial IV SHOULD NOT be present in responses without observe.


Question: For each stored security context, the first time after boot the server receives an OSCORE request, the server uses the Repeat option I-D.amsuess-core-repeat-request-tag to get a request with <del> verifiable freshness and uses that to synchronize the replay window.  If the server can verify the fresh request, the Partial IV in the fresh request is set as the lower limit of the replay </del> <ins> verifiable freshness. The Request option in the server's response MUST be encrypted, and the server MUST NOT use the same nonce as the request in its reply. If the server can verify a second request as fresh, the Partial IV of the second request is set as the lower limit of the replay </ins> window. 6.5.3.

(This refer to: https://core-URL ) The processing for protecting and verifying responses, as of now, specifies that: if Observe -> use the Partial IV in the response if not Observe -> use Partial IV of the request Should this part be changed to: if Partial IV present in the message -> use that Partial IV if not present -> use Partial IV of the request
Need to read text, but this reflects what I wanted to see.
Sorry NAME when you say "this" do you mean That's not currently included (so no text about it yet). The text right now is:
I was talking about the should change to
Section 5 - You have defined a 'sid' and said that it could be placed in the unprotected field, however you have also said that the unprotected field must be empty. These statements are contradictory
As per Christian Amsüss' message from 2017-01-05 there still seems to be confusing text in that section.
Answering both to NAME and NAME (URL) The point here is: when defining the 'sid' as a new COSE Header parameter, there is no reason related to security that would make this a "MUST be placed in the protected bucket", so instead it is a MAY. But when used in OSCOAP, the 'sid' is used in a way that it MUST be in the protected part, so the unprotected SHALL be empty. The 'sid' is analogous to 'kid' from this point of view, it is defined as a COSE parameter that MAY be unprotected, but is used protected.
Multicast removed in branch v-02 Hello OSCOAP authors, some more questions came up: 5.2 gives the context for the Encstructure as "Encrypted", while cose-msg-24 would set a "Encrypt0". Why does that differ here? states that the '"unprotected" field [...] SHALL be empty', but above states that sid 'can be placed in the unprotected headers bucket'. How do those statements go together? How are sequence numbers (which are sorted integers) mapped to partial IVs? Which endianness is used? (The padding direction follows from cose-msg-24 3.1). I'd assume (and implement) that big-endian is used because it aligns naturally with COSE's left-padding, but as I see it, that does not strictly follow from the draft.


Question: For each stored security context, the first time after boot the server receives an OSCORE request, the server uses the Repeat option I-D.amsuess-core-repeat-request-tag to get a request with <del> verifiable freshness and uses that to synchronize the replay window.  If the server can verify the fresh request, the Partial IV in the fresh request is set as the lower limit of the replay </del> <ins> verifiable freshness. The Request option in the server's response MUST be encrypted, and the server MUST NOT use the same nonce as the request in its reply. If the server can verify a second request as fresh, the Partial IV of the second request is set as the lower limit of the replay </ins> window. 6.5.3.

I concluded that the tag is always the last bytes of the ciphertext from example A.4, but did not find text in the spec to support that; what made me especially unsure about this is that the COSEEncrypt0 definition of cose-msg-24 5.2 only mentions the ciphertext there, which may be nil. Best regards Christian To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom