Question: data received, as specified in Section 8.1 of QUIC-TRANSPORT.  If no additional data can be sent, the server's PTO timer MUST NOT be armed until datagrams have been received from the client, because packets <del> sent on PTO count against the anti-amplification limit.  Note that the server could fail to validate the client's address even if 0-RTT is accepted. </del> <ins> sent on PTO count against the anti-amplification limit. When the server receives a datagram from the client, the amplification limit is increased and the server resets the PTO timer. If the PTO timer is then set to a time in the past, it is executed immediately.  Doing so avoids sending new 1-RTT packets prior to packets critical to the completion of the handshake.  In particular, this can happen when 0-RTT is accepted but the server fails to validate the client's address. </ins> Since the server could be blocked until more datagrams are received from the client, it is the client's responsibility to send packets to

Text and pseudocode have been updated.
I just updated the pseudocode as well, since it's quite straightforward.
When the PTO is not armed due to the amplification limit and then a packet is received: URL, it's important to send data for the PN spaces the PTO is armed for(Initial or Handshake) prior to new application data. Typically PTO suggests writing new data instead of retransmitting data which may or may not be lost, but that's not true during the handshake. This is only an issue for the server, since it's caused by enforcing the amplification limits prior to address confirmation. This is most evident when 0-RTT is accepted, but address validation fails, since otherwise a server would not usually have enough data to write to create a problem.
I went and double checked the msquic code , and we always re-enable the loss detection timer when we become "unblocked" by amplification protection logic. I thought this logic was already driven by some statement in the spec. I just went back and found this: Do we need any more than this?
The potential issue is that if the PTO is armed, but should have already expired, it's important to execute it prior to sending any pending data. I'm working on a PR to make this clearer, and we can whether the extra clarification is necessary?
I wonder whether there is something else going on. Amplification or not, 0-RTT packets can only be acknowledged by ACK frames in 1-RTT packets. Those can only be received after the client gets the 1-rtt keys. So implementation should just start a short timer after the handshake completes.
This seems like an editorial change, please confirm. Either way, lets ensure NAME has an opportunity to comment before landing any changes.
ngtcp2 has dedicated code for this situation: URL I feel this is a kind of optimization or implementation techniques.
In response to NAME If the WG establish a consensus on the need for a change a particular fix then this PR can be applied in the AUTH48 with AD approval. I think we need to figure out if not merging the PR until AUTH48 is the best?


Question: data received, as specified in Section 8.1 of QUIC-TRANSPORT.  If no additional data can be sent, the server's PTO timer MUST NOT be armed until datagrams have been received from the client, because packets <del> sent on PTO count against the anti-amplification limit.  Note that the server could fail to validate the client's address even if 0-RTT is accepted. </del> <ins> sent on PTO count against the anti-amplification limit. When the server receives a datagram from the client, the amplification limit is increased and the server resets the PTO timer. If the PTO timer is then set to a time in the past, it is executed immediately.  Doing so avoids sending new 1-RTT packets prior to packets critical to the completion of the handshake.  In particular, this can happen when 0-RTT is accepted but the server fails to validate the client's address. </ins> Since the server could be blocked until more datagrams are received from the client, it is the client's responsibility to send packets to

It makes it simple to provide the changes to the RFC-editor, but maybe makes it harder for the rest of the community to keep track of the changes if there are no editors copy that contain all agreed things. However, considering the hopefully limited time that may make sense.
We can tag the versions that entered the RFC Editor queue, and then generate a diff against those at AUTH48.
That tag already exists, so we are good.
At the moment, states, quote: "Clients MUST ensure that UDP datagrams containing only Initial packets are sized to at least 1200 bytes, adding padding to packets in the datagram as necessary." I think this is incorrect and that "only" should be dropped, as it excludes a UDP datagram that contains an Initial and a 0-RTT packet. Pointed out by NAME in .
Technically a design change. I think that it should be any packets that contain Initial and don't contain Handshake or 1-RTT packets. At least, that's what I implemented.
I'll note that I think there are other requirements formulated in other sections. Perhaps define a term such a minimal initial datagram size and have the requirement in one place rather than sprinkling 1200 bytes in multiple places where it can be difficult to get the finer points (such as UDP vs QUIC packets and with or without header size). For example section 14 in transport:
NAME What you implemented should be fine. However, Initial + 0-RTT coalesced in a datagram should be padded I believe and I don't think we're clear on that today.
It might be simpler to require every UDP packet that contains an Initial be padded to at least 1200? I'm worried that only requiring that of Initial if there is no Handshake/1-RTT present might be tricky on the receiver: what do I do if I receive a non-padded Initial with Handshake but I can't decrypt the Handshake data?
NAME What we are talking here is a requirement specific to clients, and I am not sure if a client has a chance of sending Initial and Handshake packets at the same time. Quoting of the TLS draft, "a client MUST discard Initial keys when it first sends a Handshake packet."


Question: data received, as specified in Section 8.1 of QUIC-TRANSPORT.  If no additional data can be sent, the server's PTO timer MUST NOT be armed until datagrams have been received from the client, because packets <del> sent on PTO count against the anti-amplification limit.  Note that the server could fail to validate the client's address even if 0-RTT is accepted. </del> <ins> sent on PTO count against the anti-amplification limit. When the server receives a datagram from the client, the amplification limit is increased and the server resets the PTO timer. If the PTO timer is then set to a time in the past, it is executed immediately.  Doing so avoids sending new 1-RTT packets prior to packets critical to the completion of the handshake.  In particular, this can happen when 0-RTT is accepted but the server fails to validate the client's address. </ins> Since the server could be blocked until more datagrams are received from the client, it is the client's responsibility to send packets to

And even if there is a possibility of a client sending Initial and Handshake at the same moment, I do not think requiring the client to pad a packet that contains only an Initial is correct, as coalescing is an optional behavior to the send side. It would mean that clients coalescing the QUIC packets would send a non-padded datagram, while clients not coalescing would send a padded datagram. That seems like an odd behavior.
And yet another issue gets sucked into the wormhole that is the key discard mess. I guess that we will have to make a final determination based on the outcome of that stuff.
On consideration, I think that the requirement is simple and we don't have to stress about interactions with discarding keys. If the packet contains an Initial, it's possible that the Initial packet is the only packet that can be used by a server. Therefore, the datagram should be padded to 1200, regardless of whatever else is included. So we strike the "only" and we're good. See 6cfcbe26385f17072ccd330aea619f65bf3bdcb4.
I wonder - if 0-RTT does not have huge certificates, would it not make sense to permit small packets in this case, provided the auth token validates. But in other cases 1200 bytes must be provided. But since 0-RTT might fail, this could then require a retransmission. Resource constrained devices might be prefer the latter.
NAME Regardless of 0-RTT, for bandwidth constrained deployments, it makes sense for a client to always send a small packet and let the server validate the path. That said, the chartered goal of V1 is to reduce the connection establishment latency, and we have explicitly decided to require clients to send full-sized packets until the path is validated. I do not think we should revisit that design. Maybe we can in v2.
I do not believe that this is necessarily correct. The reason is that we have not yet nailed down Initial key discard and in at least one version, an Initial ACK would appear in the client's second flight, but that need not be padded.
I think the specification should mandate padding of server initial packets as well.


Question: data received, as specified in Section 8.1 of QUIC-TRANSPORT.  If no additional data can be sent, the server's PTO timer MUST NOT be armed until datagrams have been received from the client, because packets <del> sent on PTO count against the anti-amplification limit.  Note that the server could fail to validate the client's address even if 0-RTT is accepted. </del> <ins> sent on PTO count against the anti-amplification limit. When the server receives a datagram from the client, the amplification limit is increased and the server resets the PTO timer. If the PTO timer is then set to a time in the past, it is executed immediately.  Doing so avoids sending new 1-RTT packets prior to packets critical to the completion of the handshake.  In particular, this can happen when 0-RTT is accepted but the server fails to validate the client's address. </ins> Since the server could be blocked until more datagrams are received from the client, it is the client's responsibility to send packets to

When I was traveling a couple weeks ago, I was on a network where, when using IPv6, it allowed 1200-byte UDP packets through from client to server but blackholed them from server to client. Since our implementation pads initials in both directions, we were able to detect this failure during the handshake and fall back to TCP/TLS. If the server didn't pad its initials, we would have succeeded at the handshake but never gotten an HTTP response.
This definitely seems like a design issue. The purpose of the padding rule is solely to limit amplification, not to establish a minimum MTU. If you want some sort of MTU rule, that should be discussed separately.
This issue is marked as design. Are you suggesting I should open a separate one?
NAME I believe it is dual purpose: From the current transport draft: >The payload of a UDP datagram carrying the first Initial packet MUST be expanded to at least 1200 bytes, by adding PADDING frames to the Initial packet and/or by coalescing the Initial packet (see Section 12.2). Sending a UDP datagram of this size ensures that the network path supports a reasonable Maximum Transmission Unit (MTU), and helps reduce the amplitude of amplification attacks caused by server responses toward an unverified client address; see Section 8.
Yeah, that's dicta as far as I am concerned. I don't think we ever had consensus that we were going to enforce MTU here.
The insight I had here was this: If you are sending Initial, it is possible that this is the only packet in the datagram that can be processed by your peer. If that is the case, then a client needs to ensure that it pads the datagram as though no other packets were present. You can infer from the fact that you have Handshake keys that the server is able to process Handshake packets, and then extend that to say that if you include Handshake packets then the server won't need padding. But then you can extend that inference to saying that there is no need to send any Initial packets (as the current draft does; currently, you are not required to keep Initial keys once you are sending with Handshake keys). Either way, I figure that it is better to keep things simple and say "if Initial, pad".


Question: data received, as specified in Section 8.1 of QUIC-TRANSPORT.  If no additional data can be sent, the server's PTO timer MUST NOT be armed until datagrams have been received from the client, because packets <del> sent on PTO count against the anti-amplification limit.  Note that the server could fail to validate the client's address even if 0-RTT is accepted. </del> <ins> sent on PTO count against the anti-amplification limit. When the server receives a datagram from the client, the amplification limit is increased and the server resets the PTO timer. If the PTO timer is then set to a time in the past, it is executed immediately.  Doing so avoids sending new 1-RTT packets prior to packets critical to the completion of the handshake.  In particular, this can happen when 0-RTT is accepted but the server fails to validate the client's address. </ins> Since the server could be blocked until more datagrams are received from the client, it is the client's responsibility to send packets to

In those cases where padding ends up being excessive, it's only excessive for a short while.
I don't know where you get this from. It's total datagram size that matters, not the contents of the rest of the datagram (which is why the neqo padding strategy works). Anyway, the algorithm you propose seems fine, but it's not necessary, and therefore there's no need to specify it in the spec.
This was my thought too.
I'm not seeing a conflict between these statements. If the packet contains an Initial, the total datagram size must be at least 1200 bytes. You can achieve this by padding any packet in the payload; I don't think anyone is advocating for requiring the padding be in a particular spot.
I don't understand what "pads the datagram as though no other packets were present" is supposed to mean, then. The way neqo does this is that it puts the packets in the datagram and then pads the rest, without any regard to what keys the server might have.
Imprecise wording on my part. "pads the datagram as though no other packets were present" might be better as "as though no other packets can be processed by the server". Let's keep in mind that the proposed changes is just striking "only" in "Clients MUST ensure that UDP datagrams containing Initial packets have UDP payloads of at least 1200 bytes, [...]". I agree that this will result in larger packets than are ideal in a couple of cases. But the ACK-only Initial packets a client sent are most likely coalesced with other packets outside of cases where the padding is genuinely required.
I'm sorry, but I still don't see what benefit this change provides. Perhaps this would be easier next week.
The change makes it clear that if you send Initial+0-RTT then you should still pad to 1200. That's all. Previously, you would not have been required to pad, which would have been bad. Most of the debate and discussion is about the knock-on consequences of applying the broader rule, which I don't think are that important. And yes, the whole "when do you discard Initial keys" thing does confound things a little.
Discussed in Cupertino. The word "only" is to be removed from the respective sentence. Moving to Editorial.


Question: 4.1. <ins> The Verifier, when appraising Evidence, or the Relying Party, when appraising Attestation Results, checks the values of some claims against constraints specified in its Appraisal Policy.  Such constraints might involve a comparison for equality against a reference value, or a check for being in a range bounded by reference values, or membership in a set of reference values, or a check against values in other claims, or any other test. Such reference values might be specified as part of the Appraisal Policy itself, or might be obtained from a separate source, such as an Endorsement, and then used by the Appraisal Policy. The actual data format and semantics of any reference values are specific to claims and implementations.  This architecture document does not define any general purpose format for them or general means for comparison. 4.2. </ins> An Attester consists of at least one Attesting Environment and at least one Target Environment.  In some implementations, the Attesting and Target Environments might be combined.  Other implementations

Previously the text was specific to policy for Evidence, but the same applies to policy for appraising Attestation Results, so generalizing the text. This also removes a redundant sentence where older text and newly merged text from this morning said the same thing. And the diffs look larger than they really are, since some text was just moved around to be in a different order. Signed-off-by: Dave Thaler


Question: consider its CONNECT-UDP request as failed. The proxy that is creating the UDP socket to the destination responds <del> to the CONNECT-UDP request with a 2xx (Successful) response, and indicates it supports HTTP Datagrams by sending the corresponding registration capsule. </del> <ins> to the CONNECT-UDP request with a 2xx (Successful) response. </ins> Clients MAY optimistically start sending proxied UDP packets before receiving the response to its CONNECT-UDP request, noting however

This text was a mistake I made when converting from Datagram-Flow-Id to capsules.
Section 4 states that the proxy responds to a CONNECT-UDP request with 2xx and a corresponding registration capsule to indicate end-to-end support of datagrams. If the client sends a REGISTERDATAGRAMCONTEXT capsule, the corresponding capsule from the proxy will be of the same kind, and it will register a new server-generated context ID. So now we would have two context IDs for the same stream, which seems a bit unnecessary. Could we simply omit the step where the proxy sends a registration capsule and simply state that a 2xx response to the CONNECT-UDP request is sufficient indication of end-to-end datagram support?
My reading of the spec is different, URL says So for example, if the client sends a request on stream 4 and then REGISTERDATAGRAMCONTEXT { Context ID (0)}, the server will respond with REGISTERDATAGRAMCONTEXT { Context ID (0)} to confirm that the context is accepted.
That makes sense, I was assuming that the "used in both directions" referred to datagrams. I think my confusion in part came from the same section that says: But sending a registration capsule with an already registered context ID is not a new registration I suppose. Maybe it's good to clarify this a bit in the datagram spec. I'll open a separate issue there.
I agree the draft is a bit ambiguous here.
Indeed, the spec is unclear here, my apologies. I got this wrong when I rewrote the old Datagram-Flow-Id text. The server doesn't need to echo the registration capsule here since the client's registration is bidirectional. NAME we should add text to HTTP Datagrams to clarify what we want to do about echoing registrations, is it required allowed forbidden I'm leaning towards (3) unless we have a use case for communicating the fact that a context is "accepted" and in which case I'd say (2).
Aha! In that case I apologise too. This seems important for interop! Now I remember, I think some people felt registration ack wasn't needed as long as there was a way to reject. And we have that with CLOSEDATAGRAMCONTEXT. So I think (3), modelled as implicit accept and explicit close, sounds good. That cuts down the chatter (and probably simplifies some code in my implementation).


Question: A push service or user agent MAY also delete that receive too many push messages. <del> End-to-end confidentiality mechanisms, such as those in API, prevent an entity with a valid push message subscription URI from learning the contents of push messages.  Push messages that are not successfully authenticated will not be delivered by the API, but this can present a denial of service risk. Conversely, a push service is also able to deny service to user agents.  Intentional failure to deliver messages is difficult to distinguish from faults, which might occur due to transient network errors, interruptions in user agent availability, or genuine service outages. </del> <ins> A push service is also able to deny service to user agents. Intentional failure to deliver messages is difficult to distinguish from faults, which might occur due to transient network errors, interruptions in user agent availability, or genuine service outages. </ins> 8.5. <del> Server request logs can reveal subscription-related URIs.  Acquiring a push message subscription URI enables the receipt of messages or deletion of the subscription.  Acquiring a push URI permits the sending of push messages.  Logging could also reveal relationships between different subscription-related URIs for the same user agent. Encrypted message contents are not revealed to the push service. Limitations on log retention and strong access control mechanisms can ensure that URIs are not learned by unauthorized entities. </del> <ins> Server request logs can reveal subscription-related URIs or relationships between subscription-related URIs for the same user agent.  Limitations on log retention and strong access control mechanisms can ensure that URIs are not revealed to unauthorized entities. </ins> 9.

Pretty good. I think that we should at least try to put some MUST-strength language in regarding confidentiality, etc... That makes writing the rest of the security considerations that much easier (you don't have to worry that someone might have ignored your advice and account for it).
Looks good. Further refinements can be done later :)
There is an adequate explanation of the related W3C Push API in the Introduction. Additional references about specific API behavior in Section 9.3 and 9.4 can be removed.
Besides removing extraneous API references, informative references should be added for the separate drafts for optional content encoding and authentication.
Moving to -05. Waiting for a decision on the VAPID call for adoption.


Question: 3.2. <del> Connection establishment requires cleartext packets and is using a TLS handshake on stream 0.  Therefore it is detectable using heuristics similar to those used to detect TLS over TCP. 0-RTT connection may additional also send data packets, right after the Client Initial with the TLS client hello.  These data may be reordered in the network, therefore it may be possible that 0-RTT Protected data packets are seen before the Client Initial packet. </del> <ins> Connection establishment uses Initial, Handshake, and Retry packets containing a TLS handshake on Stream 0.  Connection establishment can therefore be detected using heuristics similar to those used to detect TLS over TCP.  A client using 0-RTT connection may also send data packets in 0-RTT Protected packets directly after the Initial packet containing the TLS Client Hello.  Since these packets may be reordered in the network, note that 0-RTT Protected data packets may be seen before the Initial packet.  Note that only clients send Initial packets, so the sides of a connection can be distinguished by QUIC packet type in the handshake. </ins> 3.3. <ins> The cleartext TLS handshake may contain Server Name Indication (SNI) RFC6066, by which the client reveals the name of the server it intends to connect to, in order to allow the server to present a certificate based on that name.  It may also contain information from Application-Layer Protocol Negotiation (ALPN) RFC7301, by which the client exposes the names of application-layer protocols it supports; an observer can deduce that one of those protocols will be used if the connection continues. Work is currently underway in the TLS working group to encrypt the SNI in TLS 1.3 TLS-ENCRYPT-SNI, reducing the information available in the SNI to the name of a fronting service, which can generally be identified by the IP address of the server anyway.  If used with QUIC, this would make SNI-based application identification impossible through passive measurement. 3.4. </ins> The QUIC Connection ID (see rebinding) is designed to allow an on- path device such as a load-balancer to associate two flows as identified by five-tuple when the address and port of one of the

Re SNI and ALPN: we can certainly point at the work in progress in TLS that will encrypt this information, but IMO the document should describe the current state of the world. I've just added something pointing to the SNI encryption document; while it seems that the tunneling technique described there could pretty clearly be applied to ALPN fronting as well, is there a reference for encrypting ALPN we can use here that doesn't leave details as an exercise for the reader?
I would actually prefer to describe the wire image of TLS and associated protocols in a separate document and just point to it because that's actually not only applicable for quic
I don't have a reference for encrypting ALPN. We don't have one. Maybe I should write one... On the plus side, it's something that benefits from the same techniques as SNI (and less likely to cause deployment issues, though that is only because we haven't ossified around it as much). As for the general point about now vs. later. One of the things we've tried to do is be very clear about what the invariants are, or what promises we are making. It's not the same thing as true ossification defense, but if we make it clear what we are committing to, maybe we won't have people relying on stuff we might want to change.


Question: 7.2.2. <ins> This document assumes that all communication between different entities is protected by HTTPS.  This protects information about which resources are the subject of request and prevents a network observer from being able to trivially correlate messages on either side of a proxy. </ins> As the time at which encapsulated request or response messages are sent can reveal information to a network observer.  Though messages exchanged between the oblivious proxy resource and the oblivious

Let's be clearer about what it means to proxy here. Also, since it is the same text, talk about TLS assumptions more directly. This will interact poorly with . Sorry about that NAME
From Vienna chat. A proxy is not a generic HTTP intermediary, and therefore is not subject to the same rules.
From NAME Generic proxies would forward unknown HTTP headers between clients and targets. We should be very clear that oblivious proxies are not generic, and should not be doing things like forwarding unknown headers arbitrarily between client and target, or target and client.
requests. This includes the Via field, the Forwarded field {{?FORWARDED=RFC7239}}, and any similar information. A client does not depend on the proxy using an authenticated and encrypted connection to the oblivious request resource, only that information about the client not be attached to forwarded requests. Obviously, you need encryption on one or the other side of the proxy, right? Probably this document should require it on the inbound side, but I don't see the text that requires it. Did I just miss it?
Yeah, it's only necessary on the inbound side, per the analysis, though the document assumes it's on both sides.


Question: Integer (non-negative with -1 as special value) <del> full coverage </del> <ins> -1 (full coverage) </ins> This property specifies the minimum length of the section of the Message, starting from byte 0, that the application requires to be

I'm not quite sure what I meant by "Only full coverage is guaranteed, any other requests are advisory". I assume we mean that even if a partial checksum is requested you get full coverage because requesting partial coverage and getting no checksum doesn't seem right...?
Exactly, and you made it clearer. Thanks!


Question: The server's key exchange parameters. <del> For non-anonymous key exchanges, a signature over the server's key exchange parameters. </del> <ins> For non-anonymous key exchanges, a signature over the client and server hello random data and the server's key exchange parameters. </ins> If the client has offered the "signature_algorithms" extension, the signature algorithm and hash algorithm MUST be a pair listed in that

This change clarifies that the signature over ServerDHParams data is a signature over the hash of the client + server hello random random data and the ServerDHParams data. I believe this small regression was introduced in TLS1.2 with the result that the TLS1.2 RFC (and current TLS1.3 draft) does not contain sufficient detail to implement TLS + DHE. All TLS1.2 clients and servers that I have tested do include the hello random data (and omitting it would leave implementations open to replay attacks).
Thanks for the PR. Note that the formal PDU definitions here appear to be correct, so there should be enough information to implement things correctly: I agree it wouldn't hurt to have the explanatory text be clearer. However, in TLS 1.2 we stopped explicitly saying that things were hashed before signing (because we are treating signing as a primitive), so we probably don't want to say "hash". Maybe just say a signature over the random values and the params?
Ah, this explains my confusion. After reading section 7.4.1.4.1, I formed the opposite impression about signing; that hashing and signing are explicitly different primitive operations and may be composed in a variety of ways. But I see how that "digitally-signed" seems to be a reserved term that implies both operations.
I'm not trying to discourage you here. If you were confused, others will probably be as well, so if you have some text that you think would clear this up, it would be welcome.
Thanks! I've updated the PR with an even simpler diff that I think would have made me less confused when I got to it.


Question: control application were shown in Section 2.2 of RFC7390. An application group can be named in many ways through different <del> types of identifiers, such as numbers, URIs or other strings.  An application group name or identifier, if explicitly encoded in a CoAP request, is typically included in the path component or in the query component of a Group URI.  It may also be encoded using the Uri-Host Option RFC7252 in case application group members implement a virtual CoAP server specific to that application group.  The application group can then be identified by the value of the Uri-Host Option and each virtual server serves one specific application group.  However, encoding the application group in the Uri-Host Option is not the preferred method because in this case the application group cannot be encoded in a Group URI, and also the Uri-Host Option is being used for another purpose than encoding the host part of a URI as intended by RFC7252 - which is potentially confusing.  Appendix A of I-D.ietf- core-resource-directory shows an example registration of an application group into a Resource Directory (RD), along with the CoAP group it uses and the resources supported by the application group. In this example an application group identifier is not explicitly encoded in the RD nor in CoAP requests made to the group, but it implicitly follows from the CoAP group used for the request.  So there is a one-to-one binding between the CoAP group and the application group.  The "NoSec" security group is used. A best practice for encoding application group into a Group URI is to use one URI path component to identify the application group and use the following URI paths component(s) to identify the resource within this application group.  For example, /<groupname>/res1 or /base/<groupname>/res1/res2 conform to this practice.  An application group identifier (like <groupname>) should be as short as possible when used in constrained networks. </del> <ins> types of identifiers, such as name string, number, URI or other type of string.  An application group name may be explicitly encoded in a CoAP Group URI, or it may be not included in the Group URI.  This is an implementation-specific decision.  If the application group name is explicitly encoded in a CoAP Group URI, it can be encoded within one of the URI path component: this is the most common and RECOMMENDED method to encode the application group name.  A best practice for encoding application group into a Group URI is to use one URI path component to identify the application group and use the following URI paths component(s) to identify the resource within this application group.  For example, /<groupname>/res1 or /base/<groupname>/res1/res2 conform to this practice.  An application group name (like <groupname>) should be as short as possible when used in constrained networks. URI query component: using this method, the query may consist of the group name (?<groupname>) or it may be one parameter of the query (?g=<groupname> or ?param1=value1&gn=<groupname>). URI host subcomponent: using this method, the application group becomes equal to the CoAP group.  This can only be used if there is a one-to-one mapping between CoAP groups and application groups. URI port subcomponent: using this method, the application group is identified by a number that is encoded in some way in the destination port. There are also methods to encode the application group name within the CoAP request even though it is not encoded within the Group URI. Examples of such methods are: encode in a Uri-Host Option RFC7252 which is added to the CoAP request by the client before sending it out.  Each CoAP server that is part of the CoAP group, receiving this request, decodes the Uri-Host Option and treats it as an application group name. (It can also treat the application group name in this Option as a "virtual CoAP server" specific to that application group, exactly in the same way that the Uri-Host Option was intended to allow support for multiple virtual servers hosted on the same port.  The net effect of both treatments is the same.) encode in a new (custom/application-specific) CoAP Option which is added to the CoAP request by the client before sending it out. Each CoAP server that is part of the CoAP group, receiving this request, would by design understand this Option, would decode it, and treat it as an application group name. Finally, it is possible to not encode the application group name at all within the CoAP request.  This yields the most compact representation on the wire.  In this case, each CoAP server needs to determine the application group based on contextual information, such as client identity and/or target resource.  For example, each application group on a server could have a unique set of resources that does not overlap with any resources of other application groups. Appendix A of I-D.ietf-core-resource-directory shows an example registration of an application group into a Resource Directory (RD), along with the CoAP group it uses and the resources supported by the application group.  In this example an application group name "lights" is encoded in the "ep" (endpoint) attribute of the RD registration entry.  The CoAP group is ff35:30:2001:db8:f1::8000:1 and the "NoSec" security group is used. </ins> A security group is identified by a stable and invariant string used as group name, which is generally not related with other kinds of

more details on encoding application group name, for
Reading the paragraph after "An application group can be named in many ways", I was left a bit confused: Why should it be encoded in the Uri-Query? That'd need coordination among all applications running on that host (for it is interfering with the query argument space that's usually left for the application to use). The common partitioning of applications inside a host is left-to-right in the URI, and that puts it in the very last spot. I think I do see what is meant by the discouragement of using the Uri-Host, but doubt that it'd be immediately obvious to general readers. How I understand Uri-Host to be impractical here is that while the request is sent to a well-defined and named URI, the response is a representation of the same URI with the individual server's IP replaced into the authority component, and if two application groups on the same CoAP group use the same path, then there may be clashes, not on the request-response layer (where the responses are bound to request for a particular host name) but in the client's cache of the responses. (And once one is at the point where application groups in the same CoAP group have a disjunct path set, one can do away with identification altogether and just address the unique path). I don't quite follow how this is not "as intended in RFC7252": It is an identifier for who is being addressed, and as such just part of the URI. (For example, if I define my lights group to be named URL and name the resource , then the host name is exactly the group name, and already needs to be put into the request unless there is known URI aliasing). See also URL on "send a Uri-Host" option, with the caveat that I'm a strong proponent of answer A2. Furthermore, the text seems to imply that virtual hosting is something a server would need to go out of its way to implement. It isn't: The Uri-Host option is critical, and a host needs to make the conscious decision to ignore that option; otherwise it's just as much part of finding the addressed resource as all the other Uri-* options are.


Question: control application were shown in Section 2.2 of RFC7390. An application group can be named in many ways through different <del> types of identifiers, such as numbers, URIs or other strings.  An application group name or identifier, if explicitly encoded in a CoAP request, is typically included in the path component or in the query component of a Group URI.  It may also be encoded using the Uri-Host Option RFC7252 in case application group members implement a virtual CoAP server specific to that application group.  The application group can then be identified by the value of the Uri-Host Option and each virtual server serves one specific application group.  However, encoding the application group in the Uri-Host Option is not the preferred method because in this case the application group cannot be encoded in a Group URI, and also the Uri-Host Option is being used for another purpose than encoding the host part of a URI as intended by RFC7252 - which is potentially confusing.  Appendix A of I-D.ietf- core-resource-directory shows an example registration of an application group into a Resource Directory (RD), along with the CoAP group it uses and the resources supported by the application group. In this example an application group identifier is not explicitly encoded in the RD nor in CoAP requests made to the group, but it implicitly follows from the CoAP group used for the request.  So there is a one-to-one binding between the CoAP group and the application group.  The "NoSec" security group is used. A best practice for encoding application group into a Group URI is to use one URI path component to identify the application group and use the following URI paths component(s) to identify the resource within this application group.  For example, /<groupname>/res1 or /base/<groupname>/res1/res2 conform to this practice.  An application group identifier (like <groupname>) should be as short as possible when used in constrained networks. </del> <ins> types of identifiers, such as name string, number, URI or other type of string.  An application group name may be explicitly encoded in a CoAP Group URI, or it may be not included in the Group URI.  This is an implementation-specific decision.  If the application group name is explicitly encoded in a CoAP Group URI, it can be encoded within one of the URI path component: this is the most common and RECOMMENDED method to encode the application group name.  A best practice for encoding application group into a Group URI is to use one URI path component to identify the application group and use the following URI paths component(s) to identify the resource within this application group.  For example, /<groupname>/res1 or /base/<groupname>/res1/res2 conform to this practice.  An application group name (like <groupname>) should be as short as possible when used in constrained networks. URI query component: using this method, the query may consist of the group name (?<groupname>) or it may be one parameter of the query (?g=<groupname> or ?param1=value1&gn=<groupname>). URI host subcomponent: using this method, the application group becomes equal to the CoAP group.  This can only be used if there is a one-to-one mapping between CoAP groups and application groups. URI port subcomponent: using this method, the application group is identified by a number that is encoded in some way in the destination port. There are also methods to encode the application group name within the CoAP request even though it is not encoded within the Group URI. Examples of such methods are: encode in a Uri-Host Option RFC7252 which is added to the CoAP request by the client before sending it out.  Each CoAP server that is part of the CoAP group, receiving this request, decodes the Uri-Host Option and treats it as an application group name. (It can also treat the application group name in this Option as a "virtual CoAP server" specific to that application group, exactly in the same way that the Uri-Host Option was intended to allow support for multiple virtual servers hosted on the same port.  The net effect of both treatments is the same.) encode in a new (custom/application-specific) CoAP Option which is added to the CoAP request by the client before sending it out. Each CoAP server that is part of the CoAP group, receiving this request, would by design understand this Option, would decode it, and treat it as an application group name. Finally, it is possible to not encode the application group name at all within the CoAP request.  This yields the most compact representation on the wire.  In this case, each CoAP server needs to determine the application group based on contextual information, such as client identity and/or target resource.  For example, each application group on a server could have a unique set of resources that does not overlap with any resources of other application groups. Appendix A of I-D.ietf-core-resource-directory shows an example registration of an application group into a Resource Directory (RD), along with the CoAP group it uses and the resources supported by the application group.  In this example an application group name "lights" is encoded in the "ep" (endpoint) attribute of the RD registration entry.  The CoAP group is ff35:30:2001:db8:f1::8000:1 and the "NoSec" security group is used. </ins> A security group is identified by a stable and invariant string used as group name, which is generally not related with other kinds of

The best practice is something I can get behind, although I suggest using no identifier on the wire (and just the disjunct set of resources) as a byte saving alternative when the administrative effort of ensuring path uniqueness can be afforded.
Thanks; we do need to improve the current text on these aspects. On Uri-Host and your example "URL" where authority component includes the application group: in this group communication example the sending client would normally DNS-resolve "URL" to a particular multicast IP address, then send the CoAP request to this multicast IP address destination, without including any Uri-Host Option. This works as long as you have a unique 1:1 association between application-group and CoAP-group. In case multiple application-groups map to a single CoAP-group, this doesn't work anymore : a client could be e.g. configured to always include the "Uri-Host" Option to indicate the hostname. Still not the preferred approach I would think. Btw I can't follow answer A2 on the CoAP-Faq, unfortunately: formulation is too complex. In some (common?) constrained use cases, the DNS name would not even be configured in the client and the client would just be configured directly with the IPv6 multicast address of the CoAP group to send it to. Then, the application-group would need to be encoded in some way still, e.g. using the Uri-Path Option. Now what our original text tried to suggest is to "misuse" a Uri-Host Option for that. So instead of using an option like: Uri-Path = group123 You would instead use an option: Uri-Host = group123 So this is not a "real" URI hostname but rather a low-level hack to let the client's CoAP stack insert by force an additional option just before sending out the CoAP request. The receiver's CoAP stack would just parse it as the ID of the application-group and not really as a URI-host. Because this gets confusing and potentially messy (proven by the present discussion !) we don't recommend it. So, trying to reiterate if one has configured Group URIs of the form coap://[mcast-ip-address]/resource on the client then by default the Uri-Host Option would get elided. The above mentioned "hack" is to put it back to encode application-group.


Question: control application were shown in Section 2.2 of RFC7390. An application group can be named in many ways through different <del> types of identifiers, such as numbers, URIs or other strings.  An application group name or identifier, if explicitly encoded in a CoAP request, is typically included in the path component or in the query component of a Group URI.  It may also be encoded using the Uri-Host Option RFC7252 in case application group members implement a virtual CoAP server specific to that application group.  The application group can then be identified by the value of the Uri-Host Option and each virtual server serves one specific application group.  However, encoding the application group in the Uri-Host Option is not the preferred method because in this case the application group cannot be encoded in a Group URI, and also the Uri-Host Option is being used for another purpose than encoding the host part of a URI as intended by RFC7252 - which is potentially confusing.  Appendix A of I-D.ietf- core-resource-directory shows an example registration of an application group into a Resource Directory (RD), along with the CoAP group it uses and the resources supported by the application group. In this example an application group identifier is not explicitly encoded in the RD nor in CoAP requests made to the group, but it implicitly follows from the CoAP group used for the request.  So there is a one-to-one binding between the CoAP group and the application group.  The "NoSec" security group is used. A best practice for encoding application group into a Group URI is to use one URI path component to identify the application group and use the following URI paths component(s) to identify the resource within this application group.  For example, /<groupname>/res1 or /base/<groupname>/res1/res2 conform to this practice.  An application group identifier (like <groupname>) should be as short as possible when used in constrained networks. </del> <ins> types of identifiers, such as name string, number, URI or other type of string.  An application group name may be explicitly encoded in a CoAP Group URI, or it may be not included in the Group URI.  This is an implementation-specific decision.  If the application group name is explicitly encoded in a CoAP Group URI, it can be encoded within one of the URI path component: this is the most common and RECOMMENDED method to encode the application group name.  A best practice for encoding application group into a Group URI is to use one URI path component to identify the application group and use the following URI paths component(s) to identify the resource within this application group.  For example, /<groupname>/res1 or /base/<groupname>/res1/res2 conform to this practice.  An application group name (like <groupname>) should be as short as possible when used in constrained networks. URI query component: using this method, the query may consist of the group name (?<groupname>) or it may be one parameter of the query (?g=<groupname> or ?param1=value1&gn=<groupname>). URI host subcomponent: using this method, the application group becomes equal to the CoAP group.  This can only be used if there is a one-to-one mapping between CoAP groups and application groups. URI port subcomponent: using this method, the application group is identified by a number that is encoded in some way in the destination port. There are also methods to encode the application group name within the CoAP request even though it is not encoded within the Group URI. Examples of such methods are: encode in a Uri-Host Option RFC7252 which is added to the CoAP request by the client before sending it out.  Each CoAP server that is part of the CoAP group, receiving this request, decodes the Uri-Host Option and treats it as an application group name. (It can also treat the application group name in this Option as a "virtual CoAP server" specific to that application group, exactly in the same way that the Uri-Host Option was intended to allow support for multiple virtual servers hosted on the same port.  The net effect of both treatments is the same.) encode in a new (custom/application-specific) CoAP Option which is added to the CoAP request by the client before sending it out. Each CoAP server that is part of the CoAP group, receiving this request, would by design understand this Option, would decode it, and treat it as an application group name. Finally, it is possible to not encode the application group name at all within the CoAP request.  This yields the most compact representation on the wire.  In this case, each CoAP server needs to determine the application group based on contextual information, such as client identity and/or target resource.  For example, each application group on a server could have a unique set of resources that does not overlap with any resources of other application groups. Appendix A of I-D.ietf-core-resource-directory shows an example registration of an application group into a Resource Directory (RD), along with the CoAP group it uses and the resources supported by the application group.  In this example an application group name "lights" is encoded in the "ep" (endpoint) attribute of the RD registration entry.  The CoAP group is ff35:30:2001:db8:f1::8000:1 and the "NoSec" security group is used. </ins> A security group is identified by a stable and invariant string used as group name, which is generally not related with other kinds of

This has the issue that the application-group name isn't present in the Group URI. if one has configured Group URIs of the form URL on the client then normally by default the authority gets resolved to some IP multicast address before sending it out, and thus while sending it the Uri-Host Option is NOT included in the CoAP encoding but elided. So the receiving server doesn't see the application-group ID because it's not encoded in the request data. (We assume here that multiple application-groups use the same CoAP-group.) Maybe we should discuss this further; what's the effort here / who ensures it / unique between what and what?
Initial text proposed in above PR! We'll merge it in by tomorrow evening, as an improvement (hopefully). What is not included yet is a statement saying that we don't recommend using the non-Group-URI methods of encoding application group name. To do so we would need to clearly state why that is not recommended; still not clear at this moment what the disadvantages of these are.


Question: WebRTC IP Address Handling Requirements <del> draft-ietf-rtcweb-ip-handling-10 </del> <ins> draft-ietf-rtcweb-ip-handling-11 </ins> Abstract

8445 8174 Future documents, not future versions Fix normative refs
Sure - happy to add text of this sort if we think it would be valuable. OK. :-) OK.
LGTM


Question: SHALL be the C509Certificate I-D.ietf-cose-cbor-encoded-cert. When the authentication credential is a CWT including a COSE_Key, <del> then CRED_x SHALL be the untagged CWT. </del> <ins> CRED_x SHALL be the untagged CWT. </ins> When the authentication credential includes a COSE_Key but is not <del> in a CWT, CRED_x SHALL be an untagged CCS. </del> <ins> in a CWT, CRED_x SHALL be an untagged CCS.  This is how RPKs are encoded, see fig-ccs for an example. </ins> <del> Naked COSE_Keys are thus dressed as CCS when used in EDHOC, which is done by prefixing the COSE_Key with 0xA108A101. </del> <ins> Naked COSE_Keys are thus dressed as CCS when used in EDHOC, in its simplest form by prefixing the COSE_Key with 0xA108A101 (a map with a 'cnf' claim).  In that case the resulting authentication credential contains no other identity than the public key itself, see identities. </ins> An example of a CRED_x is shown below:

URL I have been reading v17 and sent some comments to the authors, that I summarize here: 1) - Regarding RPK, previous versions of the document had a more detailed explanation about RPK. For example, in version v06 you had "The Initiator and the Responder MAY use different types of credentials, e.g. one uses an RPK and the other uses a public key certificate.” So RPK is included as part of the definition of authentication credential. However, v17 may have a different meaning since it seems “credentials" is defined as follows: "EDHOC relies on COSE for identification of credentials (see Section 3.5.3), for example X.509 certificates [RFC5280], C509 certificates [I-D.ietf-cose-cbor-encoded-cert], CWTs [RFC8392] and CWT Claims Sets (CCS) [RFC8392]. When the identified credential is a chain or a bag, the authentication credential CRED_x is just the end entity X.509 or C509 certificate / CWT. I assume RPK is also an authentication credential and this should be included in this text. A clarification would be worthy. 2) I assume it is possible that any two IoT devices can act as initiator but also as a responder, even between same two peers. It is the application which decides when to start EDHOC (initiator) in a particular case, correct? 3) It seems the EDHOC does not define any exchange for the key update (some sort of rekey). It seems an application at some point exchange some messages as "some event that triggered the key update.” Then the application call to EDHOC-KeyUpdate function to get a new PRK. Am I right? I am asking because looking at IKEv2, for example, and for the rekey, an exchange is required. Although it would add a little bit more complexity, wouldn’t it be sensical that EDHOC defines a 1 RTT to exchange a couple of nonces for the rekeying. Moreover, this function is defined in an Appendix. Is it mandatory to implement?
Yes. The document should talk about RPK a bit more as that is term that people might search for. Should be explained that CWT is the format EDHOC uses for raw public keys (RPK).


Question: SHALL be the C509Certificate I-D.ietf-cose-cbor-encoded-cert. When the authentication credential is a CWT including a COSE_Key, <del> then CRED_x SHALL be the untagged CWT. </del> <ins> CRED_x SHALL be the untagged CWT. </ins> When the authentication credential includes a COSE_Key but is not <del> in a CWT, CRED_x SHALL be an untagged CCS. </del> <ins> in a CWT, CRED_x SHALL be an untagged CCS.  This is how RPKs are encoded, see fig-ccs for an example. </ins> <del> Naked COSE_Keys are thus dressed as CCS when used in EDHOC, which is done by prefixing the COSE_Key with 0xA108A101. </del> <ins> Naked COSE_Keys are thus dressed as CCS when used in EDHOC, in its simplest form by prefixing the COSE_Key with 0xA108A101 (a map with a 'cnf' claim).  In that case the resulting authentication credential contains no other identity than the public key itself, see identities. </ins> An example of a CRED_x is shown below:

Hi all: I have been reading v17 and sent some comments to the authors, that I summarize here: 1) - Regarding RPK, previous versions of the document had a more detailed explanation about RPK. For example, in version v06 you had "The Initiator and the Responder MAY use different types of credentials, e.g. one uses an RPK and the other uses a public key certificate.” So RPK is included as part of the definition of authentication credential. However, v17 may have a different meaning since it seems “credentials" is defined as follows: "EDHOC relies on COSE for identification of credentials (see Section 3.5.3), for example X.509 certificates [RFC5280], C509 certificates [I-D.ietf-cose-cbor-encoded-cert], CWTs [RFC8392] and CWT Claims Sets (CCS) [RFC8392]. When the identified credential is a chain or a bag, the authentication credential CRED_x is just the end entity X.509 or C509 certificate / CWT. I assume RPK is also an authentication credential and this should be included in this text. A clarification would be worthy. 2) I assume it is possible that any two IoT devices can act as initiator but also as a responder, even between same two peers. It is the application which decides when to start EDHOC (initiator) in a particular case, correct? 3) It seems the EDHOC does not define any exchange for the key update (some sort of rekey). It seems an application at some point exchange some messages as "some event that triggered the key update.” Then the application call to EDHOC-KeyUpdate function to get a new PRK. Am I right? I am asking because looking at IKEv2, for example, and for the rekey, an exchange is required. Although it would add a little bit more complexity, wouldn’t it be sensical that EDHOC defines a 1 RTT to exchange a couple of nonces for the rekeying. Moreover, this function is defined in an Appendix. Is it mandatory to implement? Beyond these clarifications, I think the document is ready. Best Regards. Rafa Marin-Lopez, PhD Dept.


Question: SHALL be the C509Certificate I-D.ietf-cose-cbor-encoded-cert. When the authentication credential is a CWT including a COSE_Key, <del> then CRED_x SHALL be the untagged CWT. </del> <ins> CRED_x SHALL be the untagged CWT. </ins> When the authentication credential includes a COSE_Key but is not <del> in a CWT, CRED_x SHALL be an untagged CCS. </del> <ins> in a CWT, CRED_x SHALL be an untagged CCS.  This is how RPKs are encoded, see fig-ccs for an example. </ins> <del> Naked COSE_Keys are thus dressed as CCS when used in EDHOC, which is done by prefixing the COSE_Key with 0xA108A101. </del> <ins> Naked COSE_Keys are thus dressed as CCS when used in EDHOC, in its simplest form by prefixing the COSE_Key with 0xA108A101 (a map with a 'cnf' claim).  In that case the resulting authentication credential contains no other identity than the public key itself, see identities. </ins> An example of a CRED_x is shown below:

Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: EMAIL


Question: 4.2.2. <del> [[TODO]] </del> <ins> [[OPEN ISSUE: Limiting this to one value would potentially save some bytes here, at the cost of generality.]] </ins> 4.3.

everything else is self-delimiting and is just a source of confusion (5) Replace PSK TODO with an open issue marker (6) use varints instead of remainder of message. Got a bit carried away


Question: In this version of TLS 1.3, the two input secrets are: PSK (a pre-shared key established externally or derived from the <del> resumption_main_secret value from a previous connection) </del> <ins> resumption_secret value from a previous connection) </ins> (EC)DHE shared secret (ecdhe-shared-secret-calculation)

While we're renaming these anyway, exportersecret and resumptionsecret are just as descriptive.
exportermainsecret and resumptionmainsecret strike me as not needing an adjective in the middle at all. Perhaps exportersecret and resumptionsecret? For the exporter secret, dropping "main" avoids the acronym collision with the EMS extension, and there are no other secrets associated with exporters, so there's no use in designating this as the main one. For the resumption secret, there is a potential confusion between resumption[main]secret and the derived PSK associated with the ticket (section {#NSTMessage}), but we don't seem to give the latter a name in the first place so I think that's fine. This also gives us nice short KDF labels when we're able to change those: "exporter" and "resumption". (Or perhaps even "export" and "resume" if those don't fit in a hash block.)


Question: 3.1. A GNAP AS offering RS-facing services can publish its features on a <del> well-known discovery document using the URL ".well-known/gnap-as-rs". </del> <ins> well-known discovery document using the URL ".well-known/gnap-as-rs" appended to the grant request endpoint URL. </ins> <del> This endpoint contains a JSON document RFC8259 consisting of a single JSON object with any combination of the following optional fields: </del> <ins> The discovery response is a JSON document RFC8259 consisting of a single JSON object with the following fields: </ins> <del> The URL of the endpoint offering introspection. </del> <ins> OPTIONAL.  The URL of the endpoint offering introspection.  The location MUST be a URL RFC3986 with a scheme component that MUST be https, a host component, and optionally, port, path and query components and no fragment components. </ins> A list of token formats supported by this AS. <del> The URL of the endpoint offering resource registration. The grant endpoint of the GNAP AS. </del> <ins> The URL of the endpoint offering resource registration.  The location MUST be a URL RFC3986 with a scheme component that MUST be https, a host component, and optionally, port, path and query components and no fragment components. REQUIRED.  The location of the AS's grant request endpoint, used by the RS to derive downstream access tokens.  The location MUST be a URL RFC3986 with a scheme component that MUST be https, a host component, and optionally, port, path and query components and no fragment components.  This URL MUST be the same URL used by client instances in support of GNAP requests. OPTIONAL.  A list of the AS's supported key proofing mechanisms. The values of this list correspond to possible values of the "proof" field of the key section of the request. </ins> 3.2.

Expands the discovery document and aligns it with changes made to the discovery process in core. Addresses
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! :hammer: Explore the source changes: ac397efc4f491e2003a3f8059eef765b8e3075b3 :mag: Inspect the deploy log: :sunglasses: Browse the preview:


Question: 12.3.22. <ins> [TODO: Discuss: should we remove this?  Whether we need this or the other depends on how we want to implement multi-streaming.  We don't need both, so we should make a decision.] </ins> Integer Message Property - see msg-niceness. Note that this property is not a per-message override of the connection Niceness - see conn-niceness.  Both Niceness properties <del> may interact, but can be used indepentendly and be realized by </del> <ins> may interact, but can be used independently and be realized by </ins> different mechanisms. 12.3.23.

I didn't like something about reliability (let's not throw an error when we can't be UNreliable, only when we can't be reliable). I updated the text on ordering a bit, to say that the Property is ignored for the first Message on a Connection, and rephrased it slightly to talk about the receiver-side transport system and the receiving application - before, the text might have talked about a sender-side behavior. I added a TODO DISCUSS comment about per-message Niceness.
Fine with me, maybe fix minor knitThanks, all good now I think.


Question: The payload of this packet contains CRYPTO frames and could contain PING, PADDING, or ACK frames.  Handshake packets MAY contain CONNECTION_CLOSE frames of type 0x1c.  Endpoints MUST treat receipt <del> of Handshake packets with other frames as a connection error. </del> <ins> of Handshake packets with other frames as a connection error of type PROTOCOL_VIOLATION. </ins> Like Initial packets (see discard-initial), data in CRYPTO frames for Handshake packets is discarded - and no longer retransmitted - when

Because it always is.
I'm checking "MUST treat" in the transport draft. Sec 17.2.4 says: This is only the place where the type of a connection error is NOT specified. This part should be modified as "a connection error of XXX".
This was deliberate, but you can now send CONNECTION_CLOSE in this case, so it makes sense to use a code here.


Question: 7.3. <ins> The Oblivious Gateway Resource can be operated by a different entity than the Target Resource.  However, this means that the client needs to trust the Oblivious Gateway Resource not to modify requests or responses.  This analysis concerns itself with a deployment scenario where a single server provides both the Oblivious Gateway Resource and Target Resource. </ins> A server that operates both Oblivious Gateway and Target Resources is responsible for removing request encryption, generating a response to the Encapsulated Request, and encrypting the response.

NAME noted that it was important to note that the Gateway needs to be trusted if gateway != target. As a practical matter, that means that you probably want gateway == target.
Hi, Since the gateways are seeing request/response pairs, there is a potential here for a side-channel attack at the gateway itself or at a relay. (if I understood the draft correctly - if not, please clarify my misunderstanding here). Are there mitigations planned for this type of issue that you could expand on in the Security Considerations section perhaps?
Does the new text in address this concern?
I don't think so, because the claim is the gateway does not have intimate knowledge of the contents of the request/response. If that assertion is true, the gateway shouldn't be able to ascertain information about the actual contents from those pairs (directly or indirectly, via a side-channel attack). If the burden is on the application developer to ensure that request/response pairs traversing the gateway are to be resilient to side-channel attacks of those pairings, then it would be good to explicitly call that out in this spec (perhaps in the security considerations section?) Thoughts?
NAME the gateway necessarily sees all request and response pairs, and will therefore always learn information about each transaction. This is fundamental to the design. Whether or not the gateway uses that information for malicious purposes, e.g., by providing different responses to different requests for the same target resource, depends on the trust model. And the change in addresses that. I don't think further text is needed here.
"Finally, a relay can also generate responses, though it assumed to not be able to examine the content of a request (other than to observe the choice of key identifier, KDF, and AEAD), so it is also assumed that it cannot generate an Encapsulated Response." I feel that a relay could certainly perform a side-channel attack here as well using R/R pairings.
Can you please be more specific here? What type of attack could the relay do to violate client privacy that is not already documented in the draft?
Typically in HTTPs scenarios, it is more difficult to perform side channel attacks as a flow observer, especially if multiplexing of requests and responses are performed.


Question: 7.3. <ins> The Oblivious Gateway Resource can be operated by a different entity than the Target Resource.  However, this means that the client needs to trust the Oblivious Gateway Resource not to modify requests or responses.  This analysis concerns itself with a deployment scenario where a single server provides both the Oblivious Gateway Resource and Target Resource. </ins> A server that operates both Oblivious Gateway and Target Resources is responsible for removing request encryption, generating a response to the Encapsulated Request, and encrypting the response.

In this design, if I understand it correctly, the requests and responses are being broken out into distinct exchanges that the relay can see and therefore it makes it easier for a relay to perform these types of attacks that would be more difficult had the relay not been used in the first place. If my understanding of the protocol is incorrect here, please feel free to point that out.
You seem to be describing fingerprinting attacks, wherein the observer uses features extracted from otherwise encrypted traffic to try and learn information about the underlying (unencrypted) data. Yes, the relay does have a more fine-grained view of each exchange compared to a network observer in this protocol since it can see explicit message boundaries, and that might impact the efficacy of these attacks. This is partly already addressed in the document: We could extend this to note the relay's view of message boundaries. I don't think any additional text is needed for the gateway.
Whatever you feel is best. I think some language around the message level risks this creates vs non-relay scenarios might be helpful. Does the client intentionally break things up in a way that crosses the underlying application message boundaries (e.g. more like packetization) with a relay? I have more questions about the gateway functionality that we can discuss separately.
This means that the client really needs to trust that the gateway doesn't muck with it. As a practical matter, this incentivizes clients to choose a gateway that is effectively the same entity as the target. They don't have to, but the amount of trust required of the gateway is higher if gateway and target aren't operated by the same entity. We touch on this, but we could be clearer about it.


Question: The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption.  Even when encrypted, a scheme could embed the unencrypted length of the <del> Connection ID in the Connection ID itself, instead of remembering it, e.g. by using the first few bits to indicate a certain size of a well-known set of possible sizes with multiple values that indicate the same size but are selected randomly. </del> <ins> Connection ID in the Connection ID itself, instead of remembering it. </ins> QUIC_LB further specified possible algorithms to generate Connection IDs at load balancers.

addresses
In "Connection ID and Rebinding": "Even when encrypted, a scheme could embed the unencrypted length of the Connection ID in the Connection ID itself, instead of remembering it, e.g. by using the first few bits to indicate a certain size of a well-known set of possible sizes with multiple values that indicate the same size but are selected randomly." I almost went and filed an issue against quic-lb to do this instead of just encoding a plaintext length like it does currently. But is this a good recommended practice? ISTM that long headers would provide a bit of a Rosetta Stone for this mapping, making it not particularly effective for the complexity.
The idea was not to conceal the length but to avoid likability by identifying linked connection based on the existence of a certain length field. This might look slightly more random but I guess you also have to change your mapping more time to time. So not sure. I'm fine to remove that half sentence and maybe add a sentence about likability instead...?
Yes, I would prefer deleting the quoted text, as I think it's a solution that adds complexity for little apparent benefit.
Okay, will do that change after your PR has landed.


Question: Section 5.3 of QUIC-TLS specifies AEAD usage, and in particular the use of a nonce, N, formed by combining the packet protection IV with <del> the packet number.  If multiple packet number spaces are used, the </del> <ins> the packet number.  When multiple packet number spaces are used, the </ins> packet number alone would not guarantee the uniqueness of the nonce. In order to guarantee the uniqueness of the nonce, the nonce N is calculated by combining the packet protection IV with the packet number and with the path identifier. <del> The path ID for 1-RTT packets is the sequence number of the </del> <ins> The Path ID for 1-RTT packets is the sequence number of the </ins> Connection ID as specified in QUIC-TRANSPORT.  Section 19 of QUIC- TRANSPORT encodes the Connection ID Sequence Number as a variable- length integer, allowing values up to 2^62-1; in this specification,

From PR from NAME
Let's do another editorial pass and evtl. some re-org first and then address this issue. I think we all already agreed that we only need one of the two. So we only need to decide with name we keep.
I prefer to use the name "Path ID", as it is more intuitive in the context of multipath.
The conflict was solved. LGTM.Sounds good.


Question: figterm3 shows an example message flow where the EAP-TLS server authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer <del> fails to authenticate to the EAP-TLS server and sends a TLS Error alert. </del> <ins> fails to authenticate to the EAP-TLS server and the server sends a TLS Error alert. </ins> 2.1.5.

URL
I added "604800 seconds" as suggested by Oleg. Joe suggested "Perhaps both of these should be left to the TLS spec." I would agree with this.... Thanks Joe, one comment regarding item is inline below. Joseph Salowey wrote: [Oleg] Got it. Then maybe it is worth specifying 604800 seconds in the section "5.7. Resumption" also so it will be clear that the requirement in this section is the same strict as in "2.1.2. Ticket Establishment".


Question: Observe RFC7641 is an optional feature.  An implementation MAY support RFC7252 and the OSCORE option without supporting RFC7641, in <del> which case the Observe related processing specified in this section, sequence-numbers and processing can be omitted. The Observe option as used here targets the requirements on forwarding of I-D.hartke-core-e2e-security-reqs (Section 2.2.1). This section specifies Observe processing associated to the Partial IV (observe-partial-iv) and Observe processing in the presence of RFC7641-compliant intermediaries (observe-option-processing). In contrast to e.g. block-wise, the Inner and Outer Observe option are not processed independently.  Outer Observe is required to support Observe operations in intermediaries, but the additional use of Inner Observe is needed to protect Observe registrations end-to- end (see observe-option-processing). observe-without-intermed specifies a simplified Observe processing which is applicable in the absence of intermediaries. </del> <ins> which case the Observe related processing can be omitted. </ins> <del> Note that OSCORE is compliant with the requirement that a client must not register more than once for the same target resource (see Section 3.1 of RFC7641) since the target resource for Observe registration is identified by all options in the request that are part of the Cache-Key, including OSCORE. </del> <ins> OSCORE supports a reduced set of RFC7641 operations performed in intermediary nodes as specified in this section.  The use of Observe targets the requirements on forwarding of Section 2.2.1 of I- D.hartke-core-e2e-security-reqs, i.e. that observations go through any intermediate node, as illustrated in Figure 8 of RFC7641). </ins> <del> 4.1.3.4.1. To support proxy operations, the CoAP client using Observe with OSCORE MUST set Outer Observe.  If Observe was only sent encrypted end-to-end, an OSCORE-unaware proxy would not expect several responses to a non-Observe request and notifications would not reach the client.  Moreover, intermediaries are allowed to cancel observations and inform the server; forbidding this may result in processing and transmission of notifications on the server side which do not reach the client. In case of registrations or re-registrations, the CoAP client using Observe with OSCORE MUST set both Inner and Outer Observe to the same value (0).  This allows the server to verify that the observation was requested by the client, thereby avoiding unnecessary processing and transmission of notifications, since such notifications would not benefit the client. An intermediary that supports Observe MUST copy the OSCORE option in the next hop request unchanged.  Although intermediaries are allowed to re-send notifications to other clients, when using OSCORE this does not happen, since requests from different clients will have different cache keys. The Outer Observe option in the CoAP request may be legitimately removed by a proxy or ignored by a server.  In these cases, the server processes the request as a non-Observe request and produce a non-Observe response.  If the OSCORE client receives a response to an Observe request without an Outer Observe value, then it verifies the response as a non-Observe response, as specified in ver-res.  If the OSCORE client receives a response to a non-Observe request with an Outer Observe value, it stops processing the message, as specified in ver-res. </del> <ins> Inner Observe is used by default to protect the value of the Observe option between the endpoints.  Outer Observe is additionally used to support a selected set of intermediate node operations that are useful while maintaining end-to-end security.  Intermediary nodes MUST copy the OSCORE option in the next hop request unchanged. </ins> In order to support Observe processing in OSCORE-unaware intermediaries, for messages with the Observe option the Outer Code <del> SHALL be set to 0.05 (FETCH) for requests and to 2.05 (Content) for </del> <ins> MUST be set to 0.05 (FETCH) for requests and to 2.05 (Content) for </ins> responses. <ins> 4.1.3.4.1. The client MUST set both Inner and Outer Observe to the same value in the request.  In order to support the case of an intermediary node ignoring a registration request (Observe 0) and instead processing a non-Observe request (Section 2 of RFC7641), the server MUST only consider the received message a registration request if both Inner and Outer Observe are set to 0. Clients can re-register observations to ensure that the observation is still active and establish freshness again (RFC7641 Section 3.3.1).  When an OSCORE protected observation is refreshed, not only the ETags, but also the Partial IV (and thus the payload and OSCORE option) change.  The server uses the Partial IV of the new request as the 'request_piv' of new responses. Since intermediaries are not assumed to have a security context with the server, cancellation or re-registration of an observation initiated by an intermediary node is not supported. Cancellation of observation by an intermediary using the Reset message as response to a notification can still be applied. An intermediary node may forward a re-registration message, but if a proxy re-sends an old registration message from a client this will trigger the replay protection mechanism in the server which, depending on action, may result in a termination of the observation in proxy or client.  An OSCORE aware intermediary SHALL NOT initiate re-registrations of observations.  A server MAY respond to a replayed registration request with a cached notification.  The server SHALL NOT respond to a replayed registration request with a message encrypted using the Partial IV of the request. Note that OSCORE is compliant with the requirement that a client must not register more than once for the same target resource (see Section 3.1 of RFC7641) since the target resource for Observe registration is identified by all options in the request that are part of the Cache-Key, including OSCORE. </ins> 4.1.3.4.2. If the server accepts an Observe registration, a Partial IV MUST be

Back to one processing description Observe is now primarily inner Simplified processing Explicit cancellation by intermediary not supported


Question: hardware decoder capababilities, local policy) to determine the absolute minimum and maximum sizes it can receive.  If there are no known local limits, the "a=imageattr" attribute SHOULD be omitted. <ins> If these local limits preclude receiving any video, i.e., the degenerate case of no permitted resolutions, the "a=imageattr" attribute MUST be omitted, and the m= section MUST be marked as sendonly/inactive, as appropriate. </ins> Otherwise, an "a=imageattr" attribute is created with "recv" direction, and the resulting resolution space formed from the aforementioned intersection is used to specify its minimum and <del> maximum x= and y= values.  If the intersection is the null set, i.e., the degenerate case of no permitted resolutions, this MUST be represented by x=0 and y=0 values. </del> <ins> maximum x= and y= values. </ins> The rules here express a single set of preferences, and therefore, the "a=imageattr" q= value is not important.  It SHOULD be set to

This seems like a normative change. I'm not saying I'm against this, but what's the rationale?
Adam's argument in , which I found to be convincing.


Question: protocol negotiation.  TLS uses Application Layer Protocol Negotiation (ALPN) ALPN to select an application protocol.  Unless another mechanism is used for agreeing on an application protocol, <del> endpoints MUST use ALPN for this purpose.  When using ALPN, endpoints MUST immediately close a connection (see Section 10.3 in QUIC- TRANSPORT) if an application protocol is not negotiated with a no_application_protocol TLS alert (QUIC error code 0x178, see tls- errors).  While ALPN only specifies that servers use this alert, QUIC clients MUST also use it to terminate a connection when ALPN negotiation fails. </del> <ins> endpoints MUST use ALPN for this purpose. When using ALPN, endpoints MUST immediately close a connection (see Section 10.3 of QUIC-TRANSPORT) with a no_application_protocol TLS alert (QUIC error code 0x178; see tls-errors) if an application protocol is not negotiated.  While ALPN only specifies that servers use this alert, QUIC clients MUST use error 0x178 to terminate a connection when ALPN negotiation fails. </ins> An application protocol MAY restrict the QUIC versions that it can operate over.  Servers MUST select an application protocol compatible

This defines a limit on the number of packets that can fail authentication before you have to use new keys. There is a big hole here in that AES-CCM (that is, the AEAD based on CBC-MAC) is currently permitted, but we have no analysis to support either the confidentiality limits in TLS 1.3 or the integrity limits in this document. It is probably OK, but that is not the standard we apply here. So this might have to remain open until we get some sort of resolution on that issue. My initial opinion is to cut CCM from the draft until/unless an analysis is produced.
In the interest of transparency, I have added one more commit here. When I did the same for DTLS, ekr observed that if you have updated, you might safely stop trying to accept packets with the old keys rather than killing the connection. That results in loss for any packets that genuinely did want to use the exhausted keys, but that is probably less disruptive than having the connection drop. Of course, you can't always update, so closure is still likely necessary in some cases.
For what it's worth, Martin, Felix, and I put together a document which might help users do this themselves: URL
NAME Could you use that to come up with 2^16 limits and put them in the doc? I’m really wary of letting implementors roll their own
Sure! Can you please file an issue with that request? Noting anything else you'd like spelled out in detail would be helpful, too.
tl;dr We need to recommend limits on the number of failed decryptions. At one of the side discussions concentrated on the quality of the analysis of the and the applicability of that analysis to QUIC. Felix Günther, along with Marc Fischlin, Christian Janson, and Kenny Paterson have done a little analysis, based on and the we used to set limits in TLS. There are two relevant limits in this analysis: The confidentiality bound, which is usually expressed in terms of advantage an attacker gains in being able to break confidentiality of records/packets as they get more data from valid packets.


Question: protocol negotiation.  TLS uses Application Layer Protocol Negotiation (ALPN) ALPN to select an application protocol.  Unless another mechanism is used for agreeing on an application protocol, <del> endpoints MUST use ALPN for this purpose.  When using ALPN, endpoints MUST immediately close a connection (see Section 10.3 in QUIC- TRANSPORT) if an application protocol is not negotiated with a no_application_protocol TLS alert (QUIC error code 0x178, see tls- errors).  While ALPN only specifies that servers use this alert, QUIC clients MUST also use it to terminate a connection when ALPN negotiation fails. </del> <ins> endpoints MUST use ALPN for this purpose. When using ALPN, endpoints MUST immediately close a connection (see Section 10.3 of QUIC-TRANSPORT) with a no_application_protocol TLS alert (QUIC error code 0x178; see tls-errors) if an application protocol is not negotiated.  While ALPN only specifies that servers use this alert, QUIC clients MUST use error 0x178 to terminate a connection when ALPN negotiation fails. </ins> An application protocol MAY restrict the QUIC versions that it can operate over.  Servers MUST select an application protocol compatible

For instance, in AES-GCM, the analysis shows that after seeing 2^24.5 packets (almost 24 million) the attacker has a 2^-60 better chance than pure chance of winning the IND-CPA game. The forgery bound, which is again expressed as an probably of an attacker successfully creating a forged record/packet. Thanks to the analysis done previously, we know that AES-GCM and ChaCha20+Poly1305 have a forgery chance of 2^-57 after 2^60 and 2^36 forgery attempts respectively. The current text just points to TLS 1.3, which recommends the use of key updates to protect confidentiality. But TLS has a forgery tolerance of 0: a single failed forgery attempt causes the connection to break. QUIC (and DTLS) allow for multiple forgeries to be ignored, so we need to factor that in. As discussed in if we want to maintain security, we need to consider both confidentiality and integrity. For that we need two independent limits: The number of packets that are successfully encrypted and decrypted. The number of packets that are unsuccessfully decrypted. We have the former already. The latter is what this issue tracks. Once the limit is at risk of being exceeded, updating keys will force the attacker to start over. Based on Felix's recommendation I am going to suggest that we limit forgery attempts to 2^36. I have confirmed this with a close reading of the paper and concur. There is a significant difference here between AES-GCM and ChaCha20+Poly1305 but we believe that setting a single limit is the best approach. I will create a pull request to document this approach shortly. We could split the recommendation and allow a larger limit for AES-GCM, but I don't believe that 2^36 (~68 billion) is a significant barrier. For reference, if you were able to saturate a 10Gbps link with 50 byte IP packets that contained plausible QUIC packets, and the recipient didn't treat this as DoS traffic, it would take 5 minutes. If we assume that are more likely representative of potential packet rates, then the limit goes up to 10s of hours.


Question: protocol negotiation.  TLS uses Application Layer Protocol Negotiation (ALPN) ALPN to select an application protocol.  Unless another mechanism is used for agreeing on an application protocol, <del> endpoints MUST use ALPN for this purpose.  When using ALPN, endpoints MUST immediately close a connection (see Section 10.3 in QUIC- TRANSPORT) if an application protocol is not negotiated with a no_application_protocol TLS alert (QUIC error code 0x178, see tls- errors).  While ALPN only specifies that servers use this alert, QUIC clients MUST also use it to terminate a connection when ALPN negotiation fails. </del> <ins> endpoints MUST use ALPN for this purpose. When using ALPN, endpoints MUST immediately close a connection (see Section 10.3 of QUIC-TRANSPORT) with a no_application_protocol TLS alert (QUIC error code 0x178; see tls-errors) if an application protocol is not negotiated.  While ALPN only specifies that servers use this alert, QUIC clients MUST use error 0x178 to terminate a connection when ALPN negotiation fails. </ins> An application protocol MAY restrict the QUIC versions that it can operate over.  Servers MUST select an application protocol compatible

I would point out that that volume of unproductive traffic is probably a good reason to use something other than a key update to deal with the sender. A reminder that the underlying analysis assumes that packets are all 2^14 in size, which is the record size in TLS. This is ~10 times larger than typical MTU on the Internet and many QUIC packets might be smaller than that, so - at least for AES-GCM - recommending a 2^36 limit is more conservative than necessary. However, if we were to allow for different limits, we'd have to address the question of packet size, as a 2^16 byte packet will be used by some deployments. For ChaCha20+Poly1305, the only value that matters is the number of packets, so we avoid that question. Quoting from Felix's email for reference (with permission):
NAME Can I request that you review this analysis for correctness? I know that you had reservations about the claims here.
Another (simplier?) option could be to just update keys much more often. I've done performance tests with msquic on the effect of updating the key ~once per round trip. There was no noticeable effect on performance. In fact, more often than not, the key update perf tests happen to perform slightly better (within noise tolerance) than without key update. I'm not suggesting we advocate once a round trip or anything near that; more like every 2^20 packets (or 2^30 bytes?) sent or received (including failed decryptions). As I understand it, this is an ultra conservative number as far as protecting from any kind of attacks, and should be free as far as any performance impact on the connection. This also has the added benefit of exercising the key update scenario more often, which should hopefully improve interoperability of the feature.
I support a change like this, but I am not qualified to say what the thresholds should be. There certainly isn't a reason to push it to very high limits. This change would not break interoperability, so it's a good one. Banning CCM might break interoperability for someone, but I'm not too concerned, particularly if we can update all the browsers to not offer it.


Question: protocol negotiation.  TLS uses Application Layer Protocol Negotiation (ALPN) ALPN to select an application protocol.  Unless another mechanism is used for agreeing on an application protocol, <del> endpoints MUST use ALPN for this purpose.  When using ALPN, endpoints MUST immediately close a connection (see Section 10.3 in QUIC- TRANSPORT) if an application protocol is not negotiated with a no_application_protocol TLS alert (QUIC error code 0x178, see tls- errors).  While ALPN only specifies that servers use this alert, QUIC clients MUST also use it to terminate a connection when ALPN negotiation fails. </del> <ins> endpoints MUST use ALPN for this purpose. When using ALPN, endpoints MUST immediately close a connection (see Section 10.3 of QUIC-TRANSPORT) with a no_application_protocol TLS alert (QUIC error code 0x178; see tls-errors) if an application protocol is not negotiated.  While ALPN only specifies that servers use this alert, QUIC clients MUST use error 0x178 to terminate a connection when ALPN negotiation fails. </ins> An application protocol MAY restrict the QUIC versions that it can operate over.  Servers MUST select an application protocol compatible

A somewhat bigger concern is the lack of key update support in a lot of implementations: I read 9 of 15 servers as supporting it.
(Tentative) good news on CCM: Kenny identified a security analysis paper and it seems relatively simple to go from that to numbers. I am not personally concerned about support for key update. 9/15 isn't 15, but that doesn't bother me. It turns out to be a little fiddly to implement, so if people decide to drop connections that hit these limits instead, the effect isn't that bad. Of course, if you want to follow Nick's suggestion, that works too (I remember Dan Bernstein seriously suggesting a cipher that updated every record, back when I first proposed this scheme for TLS).
If we're looking for a new bound to initiate a key update, there's precedent in the SSH RFC to rekey after every 1 GB of data transferred. See
I should point out that my "9 of 15" figure is based on the interop matrix, where the client initiates an early update and the server responds. That is a different thing than a server initiating an update when required by the spec, which fewer than 9 servers might do.
Based on by Jonsson, I have calculated the bounds on the number of forgeries and encryptions for CCM. The numbers aren't great, but that probably doesn't matter much for the purposes to which CCM is generally put. (I'm using the notation from the here because that is easier to type than some of what is being used in other papers. For reference, q is the number of genuine encryptions, l is the length of each in 16 byte blocks, v is the number of forgeries, n is the key length in bits, t is the tag length in bits.) Jonsson puts the advantage an attacker has over a generic PRF at . If we assume the same numbers in the AEBounds paper for record/packet size, (this is for consistency, most QUIC packets will be much smaller, in the order of 2^7, but we might also go as high as 2^12; this being dictated by the MTU). For AES, .


Question: protocol negotiation.  TLS uses Application Layer Protocol Negotiation (ALPN) ALPN to select an application protocol.  Unless another mechanism is used for agreeing on an application protocol, <del> endpoints MUST use ALPN for this purpose.  When using ALPN, endpoints MUST immediately close a connection (see Section 10.3 in QUIC- TRANSPORT) if an application protocol is not negotiated with a no_application_protocol TLS alert (QUIC error code 0x178, see tls- errors).  While ALPN only specifies that servers use this alert, QUIC clients MUST also use it to terminate a connection when ALPN negotiation fails. </del> <ins> endpoints MUST use ALPN for this purpose. When using ALPN, endpoints MUST immediately close a connection (see Section 10.3 of QUIC-TRANSPORT) with a no_application_protocol TLS alert (QUIC error code 0x178; see tls-errors) if an application protocol is not negotiated.  While ALPN only specifies that servers use this alert, QUIC clients MUST use error 0x178 to terminate a connection when ALPN negotiation fails. </ins> An application protocol MAY restrict the QUIC versions that it can operate over.  Servers MUST select an application protocol compatible

To keep the advantage an attacker has to 2^-60 (to match the analysis in TLS), we therefore need to keep q to below 2^24.5. Somewhat unsurprisingly, that matches the numbers we have for AES-GCM. Jonsson puts the advantage for an attacker over a generic PRF at . As the first term is negligible even for large v (up to 2^64), we consider the second term alone and aim for a bound on the advantage of 2^-57 to match the analysis for other ciphers. That leaves us with . As q is already established to be 2^24.5, we can say that v should be limited to 2^25 (or if you want to be precise). (As a side note, for t=64, as in AEADAES128CCM8, the first term becomes relevant and our security bound limits the number of forgeries to 2^7, which is probably a bit limiting in practice. That's good justification for not enabling AEADAES128CCM_8 by default; though different applications might use a different target bound than 2^-57.) I'm an not a cryptographer. These papers all read like chicken-chicken-chicken. My calculations are not infallible either.
The shape of the bound seems plausible but I'll start a thread with the cryptographers to check everything
I reproduced Martin's analysis of CCM based on of the bounds by . (Myself not being an expert in producing such bounds, I found the second-level confirmation by Rogaway to be helpful.) I essentially agree with the numbers, except that --when following the same metric as the -- the advantage over an ideal PRP (instead of PRF) should be considered. This simply means losing a 1/2 factor in the bound: Confidentiality bound: yields an advantage of . I'd hence say it's fine to keep TLS 1.3's recommendation on sending max. full-sized records. Integrity bound: , hence yields an advantage of (matching the other analyses). Most importantly, I concur with Martin that AEADAES128CCM8 would need either much lower bounds or a different risk assessment: applying the same limit of would bring the advantage incurred through the bound up to .