8.  QUIC version 1 features Retry packets, which the server can send to validate the client's IP address before parsing the client's first flight.  A server that sends a Retry packet can do so before parsing versions that support retry, that document MUST specify how version negotiation (both compatible and incompatible) interacts with retry during a handshake that requires both.  For example, that could be <del> accomplished by having the server send a Retry packet first and validating the client's IP address before attempting compatible version negotiation.  In that scenario the Retry packet would be sent using the original version. </del>  <del> 9. </del>  QUIC version 1 allows sending data from the client to the server during the handshake, by using 0-RTT packets.  If a future document packets.  Alternatively, that document could specify that compatible version negotiation causes 0-RTT data to be rejected by the server. <del> 10. In order to facilitate the deployment of future versions of QUIC, designers of future versions SHOULD attempt to design their new version such that commonly deployed versions are compatible with it. For example, a successor to QUIC version 1 may wish to design its transport parameters in a way that does not preclude compatibility. 11. </del>  The security of this version negotiation mechanism relies on the authenticity of the Version Information exchanged during the possibility of cross-protocol attacks, but more analysis is still needed here. <del> 12. </del>  <del> 12.1. </del>  This document registers a new value in the QUIC Transport Parameter Registry maintained at <https://www.iana.org/assignments/quic/ of a codepoint in the 0-63 range to replace the provisional codepoint described above. <del> 12.2. </del>  This document registers a new value in the QUIC Transport Error Codes Registry maintained at <https://www.iana.org/assignments/quic/

While discussing with NAME I realized that the draft tries to be pretty clear about what are invariant properties of QUIC and VN, and what is specific to QUICv1. The Sections on Retry and 0-RTT somewhat stick out there, because those are concepts that are specific to QUICv1 and don't exist in the QUIC invariants. To make this clearer, we should have one section that contains all of our Considerations for compatibility with QUICv1 - guidance for writing specifications that define compatibility with QUICv1, such as draft-ietf-quic-v2.
0-RTT is a weird case. 0-RTT packets are sent by the client using the "old" version, but they will be received by the server after the server has completed the negotiation to the new version. There are many plausible solutions, such as: 1) Do not do both 0-RTT and version negotiation. If a session resumed ticket was received after negotiating from version=A to version=B, then the resumed connection shall use version=B. 2) Accept that 0-RTT packets are decrypted with version=A. 3) Maybe let clients recompute the 0-RTT key after the negotiation completes. All of these have pros and cons, but they should be specified.
Interaction with 0-RTT is discussed in . What's missing?
It is probably possible to express the issue in a version independent way. Something like: Client sends a first flight composed on Version A packets Midway through that flight, server receives enough data to decide to upgrade to version B Server keeps receiving Version A packets for some times after the upgrade Upgrade specification shall say what to do with these "after upgrade" packets. Also, you probably want to say how negotiation interacts with session resume. Shall the client remember that this particular session resume ticket was received after negotiating version B? Is it OK to just attempt to resume using version B? What does that do to server farms and partial upgrades? If the server farm is not completely updated, should servers list the version B in their supported version list?
My impression is that Section 9 pretty much says this already, but perhaps I'm misunderstanding what you're looking for. Could you send a PR with what you have in mind? As far as I can tell, TLS 1.3 session tickets aren't tied to a transport or application protocol, so they can be used across QUIC versions, right? This is discussed in .
I think that the draft should say that a client that receives a session ticket MUST remember the version that was negotiated in that session and attempt a connection with that version only when using the ticket. The server MAY reject resumption if the ticket version doesn't match. Yes, you could just resume with TLS and do a concurrent version upgrade. TLS won't care, but your application state might if it cares about version-specific capabilities. Especially with 0-RTT. I don't see much point in engaging with that. Just require that the version stay the same.
I believe that we may want different behavior based on whether or not the negotiated version is supported. Suppose two connections in which the client initiated a connection with version A. In the first, the server parameters contain: negotiated: version B supported: [ version A, version B] In that case, I think we agree that the client should resume using version B, and may use 0RTT. In the second case, the server parameters contain: negotiated: version B supported: [ version A] For me the second variant indicates that the server would like further connections to be initiated with version A. Could be for many reasons, but a common one would be partial deployment of version B in a server farm. In that specific case, the client may well want to resume with version A and use 0RTT of version A.
This is good input. I think that we might recommend something like that, though I don't think we need to go any further.
Unless I'm misunderstanding something, I think NAME and NAME proposals are mutually exclusive. In the second case from , the first connection will be using version B (because the server decided to perform compatible VN from A to B) and therefore the client will receive a version B resumption ticket (since tickets are sent in 1-RTT packets). So if the client then tries to resume with version A, it runs afoul of MT's . Am I missing something?
I was originally convinced of the merits of Christian's approach here (I even opened an issue on our implementation to consider it), but I've since revised that. Though - in theory - this is right, the chances that resumption is needed during the time that a cluster is partially upgraded is small enough that I don't think that it's worth the extra complication. If you have a server cluster that is rolling out v2, then it might be that you choose v2. When the client later resumes, presumably the cluster is further along with their rollout, making the odds of hitting a v1-only node low. Even with an extended rollout and a rapid resumption, which should be rare, the cost of that is a Version Negotiation packet and a full handshake: one round trip extra, maybe two. Given the transient nature of rollouts, this seems workable. Rollback is the other case where you might encounter this sort of skew. That is something that generally only happens when things have gone pear-shaped, so I'm not going to worry too much about some extra latency there.
NAME you are assuming that a significant time elapses between initial connection and resumption. That assumption may not be true for all applications. In DoQ for example, resumption is used as an alternative to keep-alive. The interval between connection may well be on the same order of magnitude as the idle timeout -- 10 or 20 seconds.
That seems enough that circumstances could have changed, or at least that failed resumptions won't adversely affect performance.
I am trying to think how these issues play out at the TLS level. Are we going to require that implementations encode the version number in the resumption token? If we don't, then there is hardly any enforcement possible, and the arguments behind use-it-or-lose-it come to mind. But then, can implementations actually tie a TLS resumption token to a QUIC version? I think I could implement that in Picoquic, but given the "black-box" API between TLS and QUIC, I would not assume that all implementations can. Then there is of course the whole issue of tying -- or not -- versions of QUIC to versions of TLS. Or, for that matter, using something else than TLS in a future version of QUIC. And there is a specific case of V1->V2. There is no actual functional benefit to V2. If there is a performance cost, then the upgrade is going to only be used rarely...
It's trivial in my implementation, black box and all. That is, if you do 0-RTT, you have to remember a bunch of stuff with tickets, so this is just one more piece of data (4 bytes at most). So implementation-wise, I can't see any issue. Keep in mind that this performance cost occurs rarely, only during times when a cluster has uneven support AND when that uneven support covers a connect-resume cycle. Seems like it isn't worth solving generically.
It is trivial to do that in a client implementation. Not so much in a server implementation, especially those that put all the state in the encrypted token. That gets a bizarre tradeoff in which clients can decide to abide by the matching token version requirement although it might in some case impede performance, but servers have a hard time enforcing that requirement.
Why is this not trivial on the server? Since servers already need to encode TPs and h3 settings as a binary blob in the ticket, adding the version to that blob should be trivial right?
Servers do not need to use the initial settings -- this is only for clients sending 0-RTT. The servers only sends data after the negotiation has been done. Servers may need to verify that the client is not sending something excessive in 0-RTT, but they have a very good idea of what initial parameters they use by default, and thus do not need to replicate them in the blob. Might be interesting to ask server developers what they actually do.
The h3 draft states: So the server needs to store something about settings. It could be the full settings, a hash, or just a number, but it needs something if it wants to be able to ever change its settings without rotating session ticket keys at the same time. Speaking as a server developer, our stack serializes the entire settings frame into the ticket. I could imagine a server just rotating their keys when they change settings or transport parameters and not having to store data in the ticket, but it's pretty much required if you want to support multiple keys at once which is required for good performance with proper key rotation practices.
So THAT's why they are so huge! (Seriously though, that's exactly what we do as well, even though our server is not deployed in quite the same way, it's the easiest thing to do.)
OK, Google and Mozilla. I am almost convinced. Care to ask the wider group?
The nice thing there is that it trains middleboxes to support very large resumption tickets. I can think of quite a few hacks based on that property...
The normative requirement on servers is unenforceable, so I'd suggest adding it anyway - since most servers will enforce this, clients will do the work of not reusing across versions, so even servers that do not enforce will ultimately be safe. I'll write up a PR to the VN draft that mentions this in vague terms, and filed URL to add normative text to the QUICv2 draft.
Allowing Retry to retain the same version makes it a lot harder to define a transform into a compatible version because it means that the entire Retry exchange needs to be accounted for. As noted, allowing the compatible version selection to be deferred is probably the right answer, because it means that the server generating the Retry doesn't need to unwrap the Initial. However, I don't think that a naive design like that naturally retains the properties we designed for Retry. The current text seems to be disavowing any responsibility for dealing with Retry. I don't think that is acceptable. A v2 without Retry that is compatible with v1 could just ignore the Retry, but that would lose the protections we specifically built in v1. What I think needs to happen is that v2 would not be compatible with v1 unless it was able to carry the information the v2 server needs to authenticate the v1 Retry. That is, there is a function that transforms a v1 Initial that includes a token into a v2 equivalent and there is a mechanism in v2 that provides the same retryconnectionid and so URL if v2 doesn't include a similar Retry mechanism natively.
We explicitly didn't define anything concrete for protocol features that aren't invariant, such as retry. But we could add some guidelines for this. Can you suggest text?
How about we agree on a design first. Do you think that this is a reasonable approach?
Absolutely, if two versions have a similar concept of retry and similar safety mechanisms to protect it, then retry can be made to work with compatible VN if the compatibility doc describes how to convert the retry safety mechanisms.
So: Endpoints send Retry (or any stateless exchange that is equivalent) in the version that matches the thing they respond to. Endpoints that choose a compatible version can only do so if the compatible version describes how to translate what happened into something the new version can use. That seems right. What I find interesting about this is that v2 might define the same retry authentication as v1, in which case it says "if retry happened, then do the same, whether it was v1 or v2 originally". That's easy. We might also have a protocol that doesn't bother to authenticate Retry, in which case translation is as simple as "forget that you sent a Retry". Anything is possible.
I like this framing. I'll write it up as a PR unless you'd rather do it.
You're the editor :)

8. <ins> In order to facilitate the deployment of future versions of QUIC, designers of future versions SHOULD attempt to design their new version such that commonly deployed versions are compatible with it. QUIC version 1 defines multiple features which are not documented in the QUIC invariants.  Since at the time of writing QUIC version 1 is widely deployed, this section discusses considerations for future versions to help with compatibility with QUIC version 1. 8.1. </ins> QUIC version 1 features Retry packets, which the server can send to validate the client's IP address before parsing the client's first flight.  A server that sends a Retry packet can do so before parsing versions that support retry, that document MUST specify how version negotiation (both compatible and incompatible) interacts with retry during a handshake that requires both.  For example, that could be  <ins> accomplished by having the server send a Retry packet in the original version first and therefore validating the client's IP address before attempting compatible version negotiation.  If both versions support authenticating Retry packets, the compatibility defition needs to define how to authenticate the Retry in the negotiated version handshake even though the Retry itself was sent using the original version. </ins>  <ins> 8.2. QUIC version 1 uses TLS 1.3, which supports session resumption by sending session tickets in one connection that can be used in a later connection; see Section 2.2 of RFC8446.  New versions that also use TLS 1.3 SHOULD mandate that their session tickets are rightly scoped to one version of QUIC; i.e., require that clients not use them across version and that servers validate this client requirement. 8.3. </ins> QUIC version 1 allows sending data from the client to the server during the handshake, by using 0-RTT packets.  If a future document packets.  Alternatively, that document could specify that compatible version negotiation causes 0-RTT data to be rejected by the server.  <ins> 9. </ins> The security of this version negotiation mechanism relies on the authenticity of the Version Information exchanged during the possibility of cross-protocol attacks, but more analysis is still needed here.  <ins> 10. </ins>  <ins> 10.1. </ins> This document registers a new value in the QUIC Transport Parameter Registry maintained at <https://www.iana.org/assignments/quic/ of a codepoint in the 0-63 range to replace the provisional codepoint described above.  <ins> 10.2. </ins> This document registers a new value in the QUIC Transport Error Codes Registry maintained at <https://www.iana.org/assignments/quic/


negotiation (both compatible and incompatible) interacts with retry during a handshake that requires both.  For example, that could be accomplished by having the server send a Retry packet in the original <del> version first and therefore validating the client's IP address before </del>  attempting compatible version negotiation.  If both versions support authenticating Retry packets, the compatibility defition needs to define how to authenticate the Retry in the negotiated version QUIC version 1 uses TLS 1.3, which supports session resumption by sending session tickets in one connection that can be used in a later connection; see TLS.  New versions that also use TLS 1.3 SHOULD <del> mandate that their session tickets are rightly scoped to one version of QUIC; i.e., require that clients not use them across version and that servers validate this client requirement. </del>  6.3. 0-RTT, that document MUST address the scenario where there are 0-RTT packets in the client's first flight.  For example, this could be accomplished by defining which transformations are applied to 0-RTT <del> packets.  Alternatively, that document could specify that compatible version negotiation causes 0-RTT data to be rejected by the server. </del>  7.

s/and therefore/, thereby/
s/rightly/tightly s/across version/across multiple versions
s/Alternatively, t/T/

negotiation (both compatible and incompatible) interacts with retry during a handshake that requires both.  For example, that could be accomplished by having the server send a Retry packet in the original  <ins> version first thereby validating the client's IP address before </ins> attempting compatible version negotiation.  If both versions support authenticating Retry packets, the compatibility defition needs to define how to authenticate the Retry in the negotiated version QUIC version 1 uses TLS 1.3, which supports session resumption by sending session tickets in one connection that can be used in a later connection; see TLS.  New versions that also use TLS 1.3 SHOULD  <ins> mandate that their session tickets are tightly scoped to one version of QUIC; i.e., require that clients not use them across multiple version and that servers validate this client requirement. </ins> 6.3. 0-RTT, that document MUST address the scenario where there are 0-RTT packets in the client's first flight.  For example, this could be accomplished by defining which transformations are applied to 0-RTT  <ins> packets.  That document could specify that compatible version negotiation causes 0-RTT data to be rejected by the server. </ins> 7.


vulnerable according to the information contained in the vulnerability description information. <del> The task of collecting specific endpoint information from the target endpoint, that is not available from the endpoint management capability, in order to make a determination about that endpoint (vulnerability status, identification, etc.). </del> 3. A number of assumptions must be stated in order to further clarify software tools can understand and use. The enterprise has a means of identifying enterprise endpoints <del> although assertions about some details of this capability are made. </del>  The enterprise has a means of extracting relevant information about enterprise endpoints in a form that is compatible with the An endpoint management capability is assumed to be in place within the enterprise, and is expected to collect a minimum set of <del> attributes from the endpoints under management, and to establish an endpoint's identity within the scope of that domain.  Endpoint identity can be established by collecting certain attributes (as part of the minimum set of attributes) that allow for unique and persistent tracking of endpoints on the enterprise network.  Examples include, but are not limited to, IP address, MAC address, Fully Qualified Domain Names (FQDNs), pre-provisioned identifiers such as Globally Unique Identifiers (GUIDs) or copies of serial numbers, certificates, hardware identity values, or similar attributes.  All of the information collected by the endpoint management capability is </del>  stored, with appropriate metadata (i.e. timestamp), in a central <del> location.  The endpoint management capability is expected to be performed on an ongoing basis, resulting in routine, or even event- driven, collection of basic endpoint information. </del>  See data-attribute-table for information-specific details. performed in two steps: Endpoint information collected by the endpoint management <del> capability is examined. </del>  If the data possessed by the endpoint management capability is <del> insufficient, then necessary data is collected from the target endpoint. </del>  Vulnerability detection relies on the examination of different endpoint information depending on the nature of a specific endpoint's vulnerability status will have been previously collected by the Endpoint Management Capability and available in a Repository. However, in other cases, the necessary endpoint information will not <del> be readily available in a Repository and a supplemental collection will be necessary.  Of course, an implementation of an endpoint management capability may prefer to enable operators to perform supplemental collection under certain circumstances, even when sufficient information can be provided by the endpoint management capability (e.g. there may be freshness requirements for information). Supplemental collection of endpoint information for the purpose of </del>  vulnerability assessment does not necessarily need to be a pull by <del> the vulnerability assessment capability.  Under certain deployment scenarios, once the necessary detection information is known, the information beyond that which is available in the endpoint management capability can be pushed to the vulnerability assessment capability by the endpoint whenever that information changes. </del>  See data-attribute-table for information-specific details.

We should examine the vulnerability assessment process outlined in the draft and determine the alignment with SACM tasks and update as necessary.
URL
Addressed in URL During yesterday's virtual interim meeting, we discussed various open issues with respect to the Vulnerability Assessment Scenario [1] as a result of feedback that we received on the draft which you can see here [2][3]. The slide's from the meeting can be found here [4]. One issue that we didn't have a chance to discuss because we ran out of time was whether or not an endpoint management capability has the ability to push supplemental endpoint information to the vulnerability assessment capability. This question came out of a review of the following text from the Vulnerability Assessment Scenario (specifically the last sentence). "In many cases, the endpoint information needed to determine an endpoint's vulnerability status will have been previously collected by the Endpoint Management Capability and available in a Repository. However, in other cases, the necessary endpoint information will not be readily available in a Repository and a targeted collection will be necessary. Of course, an implementation of an endpoint management capability may prefer to enable operators to perform targeted collection under certain circumstances, even when sufficient information can be provided by the endpoint management capability (e.g. there may be freshness requirements for information). Targeted collection of endpoint information for the purpose of vulnerability assessment does not necessarily need to be a pull by the vulnerability assessment capability. Under certain deployment scenarios, once the necessary detection information is known, the information beyond that which is available in the endpoint management capability can be pushed to the vulnerability assessment capability by the endpoint whenever that information changes." Our main question is whether or not pushing information from the endpoint management capability to the vulnerability assessment capability is actually possible because it would not necessarily know what information it needs to push prior to the server requesting it (in which case it is probably considered a pull)? Is there a situation where the endpoint would know, in advance, what additional information is needed for an assessment without a server requesting it? If you have any thoughts on this issue, please provide feedback by May 31st. We are planning to have an updated version of the scenario for June 8th. Thanks, Danny [1] URL [2] URL [3] URL [4] URL (looks like the slides are not available just yet, but, I suspect they should be soon)

vulnerable according to the information contained in the vulnerability description information.  3. A number of assumptions must be stated in order to further clarify software tools can understand and use. The enterprise has a means of identifying enterprise endpoints  <ins> through the execution of Target Endpoint Discovery Tasks although assertions about some details of this capability are made. </ins> The enterprise has a means of extracting relevant information about enterprise endpoints in a form that is compatible with the An endpoint management capability is assumed to be in place within the enterprise, and is expected to collect a minimum set of  <ins> attributes from the endpoints under management via Collection Tasks and to establish an endpoint's identity within the scope of that domain.  Endpoint identity can be established by collecting certain identifying attributes, collectively known as the Target Endpoint Identifier, that allow for unique and persistent tracking of endpoints on the enterprise network.  Examples include, but are not limited to, IP address, MAC address, Fully Qualified Domain Names (FQDNs), pre-provisioned identifiers such as Globally Unique Identifiers (GUIDs) or copies of serial numbers, certificates, hardware identity values, or similar attributes.  To simplify the identification of an endpoint, a Target Endpoint Label may be created and assigned to refer to the Target Endpoint Identifier.  All of the information collected by the endpoint management capability is </ins> stored, with appropriate metadata (i.e. timestamp), in a central  <ins> location and used to build up a Target Endpoint Characterization Record and Target Endpoint Profile via a Target Endpoint Characterization Task.  The endpoint management capability is expected to be performed on an ongoing basis, resulting in routine, or even event-driven, collection of basic endpoint information. </ins> See data-attribute-table for information-specific details. performed in two steps: Endpoint information collected by the endpoint management  <ins> capability is examined by the vulnerability management capability through Evaluation Tasks. </ins> If the data possessed by the endpoint management capability is  <ins> insufficient, a Collection Task is triggered and the necessary data is collected from the target endpoint. </ins> Vulnerability detection relies on the examination of different endpoint information depending on the nature of a specific endpoint's vulnerability status will have been previously collected by the Endpoint Management Capability and available in a Repository. However, in other cases, the necessary endpoint information will not  <ins> be readily available in a Repository and a Collection Task will be triggered to collect it from the target endpoint.  Of course, an implementation of an endpoint management capability may prefer to enable operators to perform this collection under certain circumstances, even when sufficient information can be provided by the endpoint management capability (e.g. there may be freshness requirements for information). The collection of additional endpoint information for the purpose of </ins> vulnerability assessment does not necessarily need to be a pull by  <ins> the vulnerability assessment capability.  Over time, some new pieces of information that are needed during common types of assessments might be identified.  An endpoint management capability can be reconfigured to have this information delivered automatically.  This avoids the need to trigger additional Collection Tasks to gather this information during assessments, streamlining the assessment process. Likewise, it might be observed that certain information delivered by an endpoint management capability is rarely used.  In this case, it might be useful to re-configure the endpoint management capability to no longer collect this information to reduce network and processing overhead.  Instead, a new Collection Task can be triggered to gather this data on the rare occasions when it is needed. </ins> See data-attribute-table for information-specific details.


The Application Server then encrypts the payload.  Header fields are populated with URL-safe base-64 encoded RFC4648 values: <del> the "keyid" from the User Agent is added to both the Encryption- Key and Encryption header fields; </del> the salt is added to the "salt" parameter of the Encryption header field; and the "rs" parameter can be omitted for messages that fit within this limit.  4. A User Agent decrypts messages are decrypted as described in I-

NAME was unhappy about the freedom we offered. This doesn't remove the header field separation, but it removes most of it.
Thank you, Martin! This looks good to me.

The Application Server then encrypts the payload.  Header fields are populated with URL-safe base-64 encoded RFC4648 values:  the salt is added to the "salt" parameter of the Encryption header field; and the "rs" parameter can be omitted for messages that fit within this limit. <ins> An application server MUST NOT use other content encodings for push messages.  In particular, content encodings that compress could result in leaking of push message contents.  The Content-Encoding header field therefore has exactly one value, which is "aesgcm128". An application server MUST include exactly one entry in each of the Encryption and Encryption-Key header fields.  This allows the "keyid" parameter to be omitted from both header fields. An application server MUST NOT include a "key" parameter in the Encryption header field. </ins> 4. A User Agent decrypts messages are decrypted as described in I-


Server with other details of the push subscription. When sending a message, an Application Server generates an ECDH key <del> pair and a random salt.  The ECDH public key is encoded into the "dh" parameter of the Crypto-Key header field; the salt is encoded into message payload.  The ECDH key pair can be discarded after encrypting the message. </del>  The content of the push message is encrypted or decrypted using a content encryption key and nonce that is derived using all of these An Application combines its ECDH private key with the public key provided by the User Agent using the process described in ECDH; on receipt of the push message, a User Agent combines its private key <del> with the public key provided by the Application Server in the "dh" </del>  parameter in the same way.  These operations produce the same value for the ECDH shared secret. the shared secret derived using ECDH the concatenation of the ASCII-encoded string "WebPush: info", a <del> zero octet, the X9.62 encoding of the User Agent ECDH public key, and X9.62 encoding of the Application Server ECDH public key; that is </del>  32 octets (i.e., the output is the length of the underlying SHA-256 HMAC function output)

/cc NAME Not sure about "parameter of that same header" phrasing. Not a fan of duplicating the text about the content coding header either. Suggestions?
Yep, these are both correct. Thanks.

Server with other details of the push subscription. When sending a message, an Application Server generates an ECDH key  <ins> pair and a random salt.  The ECDH public key is encoded into the "keyid" parameter of the encrypted content coding header, the salt in the "salt" parameter of that same header (see Section 2.1 of I- D.ietf-httpbis-encryption-encoding).  The ECDH key pair can be discarded after encrypting the message. </ins> The content of the push message is encrypted or decrypted using a content encryption key and nonce that is derived using all of these An Application combines its ECDH private key with the public key provided by the User Agent using the process described in ECDH; on receipt of the push message, a User Agent combines its private key  <ins> with the public key provided by the Application Server in the "keyid" </ins> parameter in the same way.  These operations produce the same value for the ECDH shared secret. the shared secret derived using ECDH the concatenation of the ASCII-encoded string "WebPush: info", a  <ins> zero octet, and the User Agent ECDH public key and the Application Server ECDH public key, both in the uncompressed point form defined in X9.62; that is </ins> 32 octets (i.e., the output is the length of the underlying SHA-256 HMAC function output)


the "keyid" parameter of the encrypted content coding header.  The uncompressed point form defined in X9.62 (that is, a 65 octet sequence that starts with a 0x04 octet) forms the entirety of the <del> "keyid". </del>  A push service is not required to support more than 4096 octets of payload body (see Section 7.2 of RFC8030).  Absent header (86

This is the best that I can do for this one..
I think this is as good as it gets.

the "keyid" parameter of the encrypted content coding header.  The uncompressed point form defined in X9.62 (that is, a 65 octet sequence that starts with a 0x04 octet) forms the entirety of the  <ins> "keyid".  Note that this means that the "keyid" parameter will not be valid UTF-8 as recommended in RFC8188. </ins> A push service is not required to support more than 4096 octets of payload body (see Section 7.2 of RFC8030).  Absent header (86


Server are delivered to a User Agent via a Push Service. This document describes how messages sent using this protocol can be <del> secured against inspection or modification by a Push Service. </del>  Web Push messages are the payload of an HTTP message RFC7230.  These messages are encrypted using an encrypted content encoding I- authenticated and provides confidentiality and integrity, such as HTTPS RFC2818, is sufficient.  3. <del> An Application Server that has the key identifier, public key, group and format information can encrypt a message for the User Agent. </del>  The Application Server generates a new DH or ECDH key pair in the same group as the value generated by the User Agent. From the newly generated key pair, the Application Server performs a DH or ECDH computation with the public key provided by the User Agent <del> to find the shared secret.  The Application Server then generates 16 octets of salt that is unique to the message.  A random RFC4086 salt is acceptable.  These values are used to calculate the content encryption key as defined in Section 3.2 of I-D.thomson-http- encryption. </del>  The Application Server then encrypts the payload.  Header fields are populated with URL-safe base-64 encoded RFC4648 values: field; and the public key for its DH or ECDH key pair is placed in the "dh" <del> parameter of the Encryption-Key header field. </del>  An application server MUST encrypt a push message with a single record.  This allows for a minimal receiver implementation that <del> handles a single record.  If the message is 4096 octets long, or longer, this means that the "rs" parameter MUST be set to a value that is longer than the encrypted push message length. </del>  Note that a push service is not required to support more than 4096 octets of payload body, which equates to 4080 octets of cleartext, so Multiple "aesgcm128" values are not permitted. An application server MUST include exactly one entry in each of the <del> Encryption and Encryption-Key header fields.  This allows the "keyid" </del>  parameter to be omitted from both header fields. <del> An application server MUST NOT include a "key" parameter in the Encryption header field. </del>  4. A User Agent decrypts messages are decrypted as described in I- <del> D.thomson-http-encryption.  The value of the "keyid" parameter is used to identify the correct key pair, if there is more than one possible value for the corresponding subscription. </del>  A receiver is not required to support multiple records.  Such a receiver MUST check that the record size is large enough to contain 5. <del> User Agents that enforce encryption MUST expose an elliptic curve Diffie-Hellman share on the P-256 curve FIPS186.  Public keys, such as are encoded into the "dh" parameter, MUST be in the form of an uncompressed point as described in X.692. </del>  6.

Adam Langley and David Benjamin identified a risk with the proposed security design for push messages. In the existing design, a user agent shares two pieces of information with an application server that form the basis of authenticating messages. endpoint - The secrecy of the endpoint URL is used to protect the user agent from receiving unauthenticated and unwanted messages. Unfortunately, this URL is necessarily known to user agent, push service and application server, so any of those three can generate spam. DH public key - The secrecy of the Diffie-Hellman public key is relied on to ensure that a valid push message can't be sent by anyone other than the application server. Only the user agent and the application server know this information. The concern here is that a DH public key is not typically treated like a secret. That means that when it is used, there is no guarantee that an implementation won't leak bits of the public key. For instance, if an implementation isn't constant time with respect to its contents, . If this secret is leaked to the push service, then the push service is able to generate push messages that will be accepted by the user agent. Those messages will appear to come from the application server. In the modern spirit of belt-and-braces design for security protocols, this change adds a new authentication secret that the application server has to prove ownership of to send a message. This secret is mixed into the key derivation process. Any entity that doesn't know this value will be unable to derive a valid content encryption key. The suggested alternative, a HMAC key, was rejected on the basis that it increased the signaling load on the path from application server -> push service -> user agent. This provides similar protection without increasing the size of push messages. This change builds on martinthomson/http-encryption by adding the authentication secret to the context that is passed as the HKDF label.
Attention NAME
Updated to be based on martinthomson/http-encryption based on URL

Server are delivered to a User Agent via a Push Service. This document describes how messages sent using this protocol can be  <ins> secured against inspection, modification and falsification by a Push Service. </ins> Web Push messages are the payload of an HTTP message RFC7230.  These messages are encrypted using an encrypted content encoding I- authenticated and provides confidentiality and integrity, such as HTTPS RFC2818, is sufficient. <ins> 2.3. To ensure that push messages are correctly authenticated, a symmetric authentication secret is added to the information generated by a User Agent.  The authentication secret is mixed into the key derivation process described in I-D.thomson-http-encryption. The authentication secret ensures that exposure or leakage of the DH public key - which, as a public key, is not necessarily treated as a secret - does not enable an adversary to generate valid push messages. A User Agent MUST generate and provide a hard to guess sequence of octets that is used for authentication of push messages.  This SHOULD be generated by a cryptographically strong random number generator RFC4086 and be at least 16 octets long. </ins> 3.  <ins> An Application Server that has the public key, group and format information plus the authentication secret can encrypt a message for the User Agent. 3.1. </ins> The Application Server generates a new DH or ECDH key pair in the same group as the value generated by the User Agent. From the newly generated key pair, the Application Server performs a DH or ECDH computation with the public key provided by the User Agent  <ins> to find the input keying material for key derivation.  The Application Server then generates 16 octets of salt that is unique to the message.  A random RFC4086 salt is acceptable. Web push uses the authentication secret defined in Section 4.3 of I- D.thomson-http-encryption.  This authentication secret (see auth) is generated by the user agent and shared with the application server. 3.2. </ins> The Application Server then encrypts the payload.  Header fields are populated with URL-safe base-64 encoded RFC4648 values: field; and the public key for its DH or ECDH key pair is placed in the "dh"  <ins> parameter of the Crypto-Key header field. </ins> An application server MUST encrypt a push message with a single record.  This allows for a minimal receiver implementation that  <ins> handles a single record.  If the message is 4096 octets or longer, the "rs" parameter MUST be set to a value that is longer than the encrypted push message length. </ins> Note that a push service is not required to support more than 4096 octets of payload body, which equates to 4080 octets of cleartext, so Multiple "aesgcm128" values are not permitted. An application server MUST include exactly one entry in each of the  <ins> Encryption and Crypto-Key header fields.  This allows the "keyid" </ins> parameter to be omitted from both header fields.  <ins> An application server MUST NOT include an "aesgcm128" parameter in the Encryption header field. </ins> 4. A User Agent decrypts messages are decrypted as described in I-  <ins> D.thomson-http-encryption.  The authentication secret described in derivation is used in key derivation. Note that the value of the "keyid" parameter is used to identify the correct share, if there are multiple values for the Crypto-Key header field. </ins> A receiver is not required to support multiple records.  Such a receiver MUST check that the record size is large enough to contain 5.  <ins> User Agents MUST expose an elliptic curve Diffie-Hellman share on the P-256 curve FIPS186. Public keys, such as are encoded into the "dh" parameter, MUST be in the form of an uncompressed point as described in X.692 (that is, a 65 octet sequence that starts with a 0x04 octet). The label for this curve is the string "P-256" encoded in ASCII (that is, the octet sequence 0x50, 0x2d, 0x32, 0x35, 0x36). </ins> 6.


header field therefore has exactly one value, which is "aesgcm128". Multiple "aesgcm128" values are not permitted. <del> An application server MUST include exactly one entry in each of the Encryption and Crypto-Key header fields.  This allows the "keyid" parameter to be omitted from both header fields. </del>  An application server MUST NOT include an "aesgcm128" parameter in the Encryption header field.

defines: This removes a number of edge-cases and simplifies implementations. However, defines: Which is a violation of the former. Semantically it makes most sense for these to be distinct values since they're intended for different audiences. I'll propose a PR limiting webpush-encryption to one Crypto-Key entry having a value instead.
Because life is complicated, there are some libraries that are using ";" and creating a single parameter set containing both ECE and VAPID parameters, e.g. Because of "quirks" in both the mozilla and FCM handlers, this works. It may be beneficial if legacy push servers continue to support this behavior while libraries and applications that depend on them transition to any new division format.

header field therefore has exactly one value, which is "aesgcm128". Multiple "aesgcm128" values are not permitted.  <ins> An application server MUST include exactly one entry in the Encryption field, and at most one entry having a "dh" parameter in the Crypto-Key field.  This allows the "keyid" parameter to be omitted from both header fields. </ins> An application server MUST NOT include an "aesgcm128" parameter in the Encryption header field.


2. <del> For each new subscription that the User Agent generates for an application, it also generates an asymmetric key pair for use in Diffie-Hellman (DH) DH or elliptic-curve Diffie-Hellman (ECDH) ECDH. The public key for this key pair can then be distributed by the application to the Application Server along with the URI of the subscription.  The private key MUST remain secret. </del>  <del> This key pair is used with the Diffie-Hellman key exchange as described in Section 4.2 of I-D.ietf-httpbis-encryption-encoding. </del>  <del> A User Agent MUST generate and provide a public key for the scheme described in mti. </del>  <del> The public key MUST be accompanied by a key identifier that can be used in the "keyid" parameter to identify which key is in use.  Key identifiers need only be unique within the context of a subscription. </del>  2.1. <del> As described in I-D.ietf-httpbis-encryption-encoding, use of Diffie- Hellman for key agreement requires that the receiver provide clear information about its chosen group and the format for the "dh" parameter with each potential sender. </del>  <del> This document only describes a single ECDH group and point format, described in mti.  A specification that defines alternative groups or formats MUST provide a means of indicating precisely which group and format is in use for every public key that is provided. </del>  <del> 2.2. </del>  <del> The application using the subscription distributes the key identifier and public key along with other subscription information, such as the subscription URI and expiration time. </del>  <del> The communication medium by which an application distributes the key identifier and public key MUST be confidentiality protected for the reasons described in I-D.ietf-webpush-protocol.  Most applications that use push messaging have a pre-existing relationship with an Application Server.  Any existing communication mechanism that is authenticated and provides confidentiality and integrity, such as HTTPS RFC2818, is sufficient. </del>  <del> 2.3. </del>  To ensure that push messages are correctly authenticated, a symmetric authentication secret is added to the information generated by a User Agent.  The authentication secret is mixed into the key derivation process described in I-D.ietf-httpbis-encryption-encoding. <del> The authentication secret ensures that exposure or leakage of the DH public key - which, as a public key, is not necessarily treated as a secret - does not enable an adversary to generate valid push messages. A User Agent MUST generate and provide a hard to guess sequence of </del>  octets that is used for authentication of push messages.  This SHOULD be generated by a cryptographically strong random number generator <del> RFC4086 and be at least 16 octets long. </del>  <del> 3. </del>  <del> An Application Server that has the public key, group and format information plus the authentication secret can encrypt a message for the User Agent. </del>  <del> 3.1. </del>  <del> The Application Server generates a new DH or ECDH key pair in the same group as the value generated by the User Agent. </del>  <del> From the newly generated key pair, the Application Server performs a DH or ECDH computation with the public key provided by the User Agent to find the input keying material for key derivation.  The Application Server then generates 16 octets of salt that is unique to the message.  A random RFC4086 salt is acceptable. </del>  <del> Web push uses the authentication secret defined in Section 4.3 of I- D.ietf-httpbis-encryption-encoding.  This authentication secret (see auth) is generated by the user agent and shared with the application server. </del>  <del> 3.2. </del>  <del> The Application Server then encrypts the payload.  Header fields are populated with base64url encoded RFC7515 values: </del>  <del> the salt is added to the "salt" parameter of the Encryption header field; and </del>  <del> the public key for its DH or ECDH key pair is placed in the "dh" parameter of the Crypto-Key header field. </del>  <del> An application server MUST encrypt a push message with a single </del>  record.  This allows for a minimal receiver implementation that handles a single record.  If the message is 4096 octets or longer, the "rs" parameter MUST be set to a value that is longer than the encrypted push message length. <del> Note that a push service is not required to support more than 4096 octets of payload body, which equates to 4077 octets of cleartext, so the "rs" parameter can be omitted for messages that fit within this limit. </del>  <del> An application server MUST NOT use other content encodings for push </del>  messages.  In particular, content encodings that compress could result in leaking of push message contents.  The Content-Encoding <del> header field therefore has exactly one value, which is "aesgcm128". Multiple "aesgcm128" values are not permitted. </del>  <del> An application server MUST include exactly one entry in the </del>  Encryption field, and at most one entry having a "dh" parameter in the Crypto-Key field.  This allows the "keyid" parameter to be omitted from both header fields. <del> An application server MUST NOT include an "aesgcm128" parameter in the Encryption header field. </del>  <del> 4. </del>  <del> A User Agent decrypts messages are decrypted as described in I- D.ietf-httpbis-encryption-encoding.  The authentication secret described in derivation is used in key derivation. </del>  <del> Note that the value of the "keyid" parameter is used to identify the correct share, if there are multiple values for the Crypto-Key header field. </del>  <del> A receiver is not required to support multiple records.  Such a receiver MUST check that the record size is large enough to contain the entire payload body in a single record.  The "rs" parameter MUST NOT be exactly equal to the length of the payload body minus the length of the authentication tag (16 octets); that length indicates that the message has been truncated. </del>  <del> 5. </del>  <del> User Agents MUST expose an elliptic curve Diffie-Hellman share on the P-256 curve FIPS186. </del>  <del> Public keys, such as are encoded into the "dh" parameter, MUST be in the form of an uncompressed point as described in X.692 (that is, a 65 octet sequence that starts with a 0x04 octet). </del>  <del> The label for this curve is the string "P-256" encoded in ASCII (that is, the octet sequence 0x50, 0x2d, 0x32, 0x35, 0x36). </del>  <del> 6. </del>  <del> This document has no IANA actions. </del>  7.

In httpwg/http-extensions I have proposed the removal of the Diffie-Hellman pieces. This PR adopts the parts that were removed from the base spec that webpush needs. In the process, I've had to make a bunch of changes. It loses a bit of generality, which makes things easier to follow, which I've tried to capitalize on by being a lot more explicit about the overall process. . NAME NAME NAME would you mind reviewing this change to see that I haven't messed something up?

2.  <ins> Encrypting a push message uses elliptic-curve Diffie-Hellman (ECDH) ECDH on the P-256 curve FIPS186 to establish a shared secret (see dh) and a symmetric secret for authentication (see auth). </ins>  <ins> A User Agent generates an ECDH key pair and authentication secret that it associates with each subscription it creates.  The ECDH public key and the authentication secret are sent to the Application Server with other details of the push subscription. </ins>  <ins> When sending a message, an Application Server generates an ECDH key pair and a random salt.  The ECDH public key is encoded into the "dh" parameter of the Crypto-Key header field; the salt is encoded into the "salt" parameter of the Encryption header field.  The ECDH key pair can be discarded after encrypting the message. </ins>  <ins> The content of the push message is encrypted or decrypted using a content encryption key and nonce that is derived using all of these inputs and the process described in encryption. </ins> 2.1.  <ins> The application using the subscription distributes the subscription public key and authentication secret to an authorized Application Server.  This could be sent along with other subscription information that is provided by the User Agent, such as the push subscription URI. An application MUST use an authenticated, confidentiality protected communications medium for this purpose.  In addition to the reasons described in I-D.ietf-webpush-protocol, this ensures that the authentication secret is not revealed to unauthorized entities, which can be used to generate push messages that will be accepted by the User Agent. Most applications that use push messaging have a pre-existing relationship with an Application Server.  Any existing communication mechanism that is authenticated and provides confidentiality and integrity, such as HTTPS RFC2818, is sufficient. 3. Push message encryption happens in four phases: The input keying material used for deriving the content encryption keys used for the push message is derived using elliptic-curve Diffie-Hellman ECDH (dh). This is then combined with the application secret to produce the input keying material used in I-D.ietf-httpbis-encryption-encoding (combine). </ins>  <ins> A content encryption key and nonce are derived using the process in I-D.ietf-httpbis-encryption-encoding with an expanded context string (context). </ins>  <ins> Encryption or decryption follows according to I-D.ietf-httpbis- encryption-encoding. </ins>  <ins> The key derivation process is summarized in summary.  Restrictions on the use of the encrypted content coding are described in restrict. </ins>  <ins> 3.1. For each new subscription that the User Agent generates for an Application, it also generates a P-256 FIPS186 key pair for use in elliptic-curve Diffie-Hellman (ECDH) ECDH. When sending a push message, the Application Server also generates a new ECDH key pair on the same P-256 curve. </ins>  <ins> The ECDH public key for the Application Server is included in the "dh" parameter of the Crypto-Key header field (see iana).  The uncompressed point form defined in X9.62 (that is, a 65 octet sequence that starts with a 0x04 octet) is encoded using base64url RFC7515 to produce the "dh" parameter value. An Application combines its ECDH private key with the public key provided by the User Agent using the process described in ECDH; on receipt of the push message, a User Agent combines its private key with the public key provided by the Application Server in the "dh" parameter in the same way.  These operations produce the same value for the ECDH shared secret. 3.2. </ins> To ensure that push messages are correctly authenticated, a symmetric authentication secret is added to the information generated by a User Agent.  The authentication secret is mixed into the key derivation process described in I-D.ietf-httpbis-encryption-encoding.  <ins> A User Agent MUST generate and provide a hard to guess sequence of 16 </ins> octets that is used for authentication of push messages.  This SHOULD be generated by a cryptographically strong random number generator  <ins> RFC4086. </ins>  <ins> 3.3. </ins>  <ins> The shared secret produced by ECDH is combined with the authentication secret using HMAC-based key derivation function (HKDF) described in RFC5869.  This produces the input keying material used by I-D.ietf-httpbis-encryption-encoding. </ins>  <ins> The HKDF function uses SHA-256 hash algorithm FIPS180-4 with the following inputs: </ins>  <ins> the authentication secret </ins>  <ins> the shared secret derived using ECDH </ins>  <ins> the ASCII-encoded string "Content-Encoding: auth" with a terminal zero octet </ins>  <ins> 32 octets (i.e., the output is the length of the underlying SHA-256 HMAC function output) </ins>  <ins> 3.4. </ins>  <ins> The derivation of the content encryption key and nonce uses an additional context string. </ins>  <ins> The context is comprised of a label of "P-256" encoded in ASCII (that is, the octet sequence 0x50, 0x2d, 0x32, 0x35, 0x36), a zero-valued octet, the length of the User Agent public key (65 octets) encoded as a two octet unsigned integer in network byte order, the User Agent public key, the length of the Application Server public key (65 octets), and the Application Server public key. </ins>  <ins> 3.5. This results in a the final content encryption key and nonce generation using the following sequence, which is shown here in pseudocode with HKDF expanded into separate discrete steps using HMAC with SHA-256: Note that this omits the exclusive OR of the final nonce with the record sequence number, since push messages contain only a single record (see restrict) and the sequence number of the first record is zero. 4. An Application Server MUST encrypt a push message with a single </ins> record.  This allows for a minimal receiver implementation that handles a single record.  If the message is 4096 octets or longer, the "rs" parameter MUST be set to a value that is longer than the encrypted push message length.  <ins> A push service is not required to support more than 4096 octets of payload body (see Section 7.2 of I-D.ietf-webpush-protocol), which equates to 4077 octets of cleartext, so the "rs" parameter can be omitted for messages that fit within this limit. </ins>  <ins> An Application Server MUST NOT use other content encodings for push </ins> messages.  In particular, content encodings that compress could result in leaking of push message contents.  The Content-Encoding  <ins> header field therefore has exactly one value, which is "aesgcm". Multiple "aesgcm" values are not permitted. </ins>  <ins> An Application Server MUST include exactly one entry in the </ins> Encryption field, and at most one entry having a "dh" parameter in the Crypto-Key field.  This allows the "keyid" parameter to be omitted from both header fields.  <ins> An Application Server MUST NOT include an "aesgcm" parameter in the Encryption header field. </ins>  <ins> A User Agent is not required to support multiple records.  A User Agent MAY ignore the "rs" parameter.  If a record size is size is present, but unchecked, decryption will fail with high probability for all valid cases.  Decryption will also succeed if the push message contains a single record from a longer truncated message. Given that an Application Server is prohibited from generating such a message, this is not considered a serious risk. </ins>  <ins> 5. </ins>  <ins> The following example shows a push message being sent to a push service. </ins>  <ins> This example shows the ASCII encoded string, "I am the walrus".  The content body is shown here encoded in URL-safe base64url for presentation reasons only.  Line wrapping of the "dh" parameter is added for presentation purposes. </ins>  <ins> Since there is no ambiguity about which keys are being used, the "keyid" parameter is omitted from both the Encryption and Crypto-Key header fields.  The keys shown below use uncompressed points X9.62 encoded using base64url. </ins>  <ins> The sender's private key used in this example is "nCScek-QpEjmOOlT- rQ38nZzvdPlqa00Zy0i6m2OJvY".  Intermediate values for this example are included in ex-intermediate. </ins>  <ins> 6. </ins>  <ins> This document defines the "dh" parameter for the Crypto-Key header field in the "Hypertext Transfer Protocol (HTTP) Crypto-Key Parameters" registry defined in I-D.ietf-httpbis-encryption-encoding. </ins>  <ins> Parameter Name: dh Purpose: The "dh" parameter contains a Diffie-Hellman share which is used to derive the input keying material used in "aesgcm" content coding. </ins>  <ins> Reference: this document. </ins> 7.


A user agent MAY omit the subscription set if it is unable to receive push messages in an aggregated way for the lifetime of the subscription.  This might be necessary if the user agent is <del> monitoring subscriptions for other clients (see sets-streams). </del>  The push service SHOULD return the same subscription set in its response, although it MAY return a new subscription set if it is unable to receive receipts in an aggregated way for the lifetime of the receipt subscription.  This might be necessary if the application server is monitoring receipt subscriptions on the behalf of other <del> push message senders (see sets-streams). </del>  A push service MUST return a 400 (Bad Request) status code for requests which contain an invalid receipt subscription.  If a push push service.  This could force the user agent to serialize subscription requests to the push service. <del> A user agent that monitors subscriptions for other clients might require multiple subscription sets.  Each subscription set can then be managed independently, which might include being moved between user agents. </del> 8. This protocol MUST use RFC2818.  This includes any communications

I ensured that the "proxy" text in UA and AS were similar. I removed the cross-references to and added text in Section 7.5, which is specific to PS policies if it doesn't want to support multiple subscription sets. I did not call out potential UA scenarios in detail other than "monitoring on behalf" of other receivers or senders. WebPush provides a mechanism to enable proxies - but it may be better to have separate drafts that describe specific policies that use this mechanism to support scenarios such as moving between UA(s).
NAME and NAME - please review and comment.
LGTM, but I'll wait until others have commented before merging.
This works for me.

A user agent MAY omit the subscription set if it is unable to receive push messages in an aggregated way for the lifetime of the subscription.  This might be necessary if the user agent is  <ins> monitoring subscriptions on behalf of other push message receivers. </ins> The push service SHOULD return the same subscription set in its response, although it MAY return a new subscription set if it is unable to receive receipts in an aggregated way for the lifetime of the receipt subscription.  This might be necessary if the application server is monitoring receipt subscriptions on the behalf of other  <ins> push message senders. </ins> A push service MUST return a 400 (Bad Request) status code for requests which contain an invalid receipt subscription.  If a push push service.  This could force the user agent to serialize subscription requests to the push service.  8. This protocol MUST use RFC2818.  This includes any communications


be completed using HTTP/1.1, where HTTP/2 is necessary, the more verbose frame format from RFC7540 is used.  2. A general model for push services includes three basic actors: a user An application server requests the delivery of a push message by sending a HTTP POST request to a push resource distributed to the <del> application server by a user agent.  The ciphertext of the push message is included in the body of the request. </del>  5.1.

"The ciphertext of the push message is included in the body of the request." The example looks like base64 - it should be clear it's binary content ( ciphertext is not base64) If we give an example with ciphertext, it should include the extra headers. Alternative is to say "The content of the push message is included", and have a "I am walrus" example" - with a link to the encryption document for proper encrypted example. But since most implementations will require encryption - I think it's better to add the extra headers and make it clear it's binary.
I prefer the "Alternative" approach to keep the webpush examples simple and uncluttered. I will add a reference to the example in to illustrate encryption.

be completed using HTTP/1.1, where HTTP/2 is necessary, the more verbose frame format from RFC7540 is used. <ins> Examples do not include specific methods for push message encryption or application server authentication because the protocol does not define a mandatory system.  The examples in I-D.ietf-webpush-vapid and I-D.ietf-webpush-encryption demonstrate the approach adopted by the API for its requirements. </ins> 2. A general model for push services includes three basic actors: a user An application server requests the delivery of a push message by sending a HTTP POST request to a push resource distributed to the  <ins> application server by a user agent.  The content of the push message is included in the body of the request. </ins> 5.1.


A push message replacement request creates a new push message resource and simultaneously deletes any existing message resource <del> that has a matching topic.  Delivery receipts for the deleted message SHOULD be suppressed. </del>  The replacement request also replaces the stored TTL, Urgency, and any receipt subscription associated with the previous message in the 8. <del> This protocol MUST use RFC2818.  This includes any communications between user agent and push service, plus communications between the application and the push service.  All URIs therefore use the "https" scheme.  This provides confidentiality and integrity protection for subscriptions and push messages from external parties. </del>  Applications using this protocol MUST use mechanisms that provide confidentiality, integrity and data origin authentication.  The correlate communications for a given user agent.  It MUST NOT be possible to correlate any two push resource URIs based solely on their contents.  This allows a user agent to control correlation <del> across different applications, or over time. </del>  Similarly, the URIs provided by the push service to identify a push message MUST NOT provide any information that allows for correlation tcp <del> IESG (iesg@ietf.org) </del>  <del> The Web Push WG (webpush@ietf.org) </del>  HTTP Web Push

This attempts to address all of the issues identified during AD review: URL I have reviewed this document in preparation for IETF last call. It is almost ready to go. I have a few comments below. Once these are resolved and a rev published, I will request publication. = Shepherd write-up = RFC 2818 is in the downref registry already. That is the only explanation necessary for the downref. = Section 5.3 = I'm assuming the application scenarios listed in the table are illustrative since they do not cover every possible application. It would be good to note that. = Section 5.4 = "Delivery receipts for the deleted message SHOULD be suppressed." Why is this a SHOULD rather than a MUST? It seems incorrect in all cases to send a delivery receipt for a message that never gets delivered. = Section 8 = I think the first paragraph should include a normative recommendation to follow the guidance in RFC 7525 for use of TLS. = Section 8.2 = I think it would be useful to acknowledge in this section that while correlation using push URIs can be limited in the various ways described, correlation based on other information exposed by user agents may still be possible. = Section 9.3 = The Contact should be IETF Chair (per RFC 6335).

A push message replacement request creates a new push message resource and simultaneously deletes any existing message resource  <ins> that has a matching topic.  If an attempt was made to deliver the deleted push message, an acknowledgment could arrive at the push service after the push message has been replaced.  Delivery receipts for such deleted messages SHOULD be suppressed. </ins> The replacement request also replaces the stored TTL, Urgency, and any receipt subscription associated with the previous message in the 8.  <ins> This protocol MUST use RFC2818 following the recommendations in RFC7525.  This includes any communications between user agent and push service, plus communications between the application and the push service.  All URIs therefore use the "https" scheme.  This provides confidentiality and integrity protection for subscriptions and push messages from external parties. </ins> Applications using this protocol MUST use mechanisms that provide confidentiality, integrity and data origin authentication.  The correlate communications for a given user agent.  It MUST NOT be possible to correlate any two push resource URIs based solely on their contents.  This allows a user agent to control correlation  <ins> across different applications, or over time.  Of course, this does not prevent correlation using other information that a user agent might expose. </ins> Similarly, the URIs provided by the push service to identify a push message MUST NOT provide any information that allows for correlation tcp  <ins> The IESG (iesg@ietf.org) </ins>  <ins> The IETF Chair (chair@ietf.org) </ins> HTTP Web Push


is communicating and when they are communicating is protected. However, the amount of information that is exposed can be limited. <del> "Push" URIs MUST NOT provide any basis to correlate communications for a given user agent.  It MUST NOT be possible to correlate any two "push" URIs based solely on the content of the "push" URIs.  This allows a user agent to control correlation across different applications, or over time. </del>  <del> In particular, user and device information MUST NOT be exposed through the "push" URI. </del>  <del> In addition, "push" URIs established by the same user agent MUST NOT include any information that allows them to be correlated with the user agent. </del>  This need not be perfect as long as the resulting anonymity set (see RFC6973, Section 6.1.1) is sufficiently large.  A "push" URI Authorization for subscriptions is managed using "subscription" and "push" capability URLs (see CAP-URI).  A capability URL grants access <del> to a resource based solely on knowledge of the URL.  Capability URLs are used for their "easy onward sharing" and "easy client API" properties.  These make it possible to avoid relying on relationships between push services and application servers, with the protocols necessary to build and support those relationships. </del>  <del> A "subscription" or "push" URI therefore acts as a bearer token. Knowledge of the "subscription" URI implies authorization to either receive push messages or delete the subscription.  Knowledge of the "push" URI implies authorization to send push messages. </del>  Encoding a large amount of random entropy (at least 120 bits) in the path component ensures that it is difficult to successfully guess a <del> valid "subscription" or "push" URI. </del>  7.4. a "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 <del> subscription-related URIs for the same user agent. </del>  Limitations on log retention and strong access control mechanisms can ensure that URIs are not learned by unauthorized entities.

I realized that I hadn't done due diligence in adding the message URL. This should address that (I have hooks in here for acknowledgment too).

is communicating and when they are communicating is protected. However, the amount of information that is exposed can be limited.  <ins> The URIs provided for "push" resources MUST NOT provide any basis to correlate communications for a given user agent.  It MUST NOT be possible to correlate any two "push" URIs based solely on their contents.  This allows a user agent to control correlation across different applications, or over time. </ins>  <ins> Similarly, the URIs provided by the push service to identify a push message MUST NOT provide any information that allows for correlation across subscriptions.  Push message URIs for the same subscription MAY contain information that would allow correlation with the associated subscription or other push messages for that subscription. </ins>  <ins> User and device information MUST NOT be exposed through a "push" or push message URI. In addition, "push" URIs established by the same user agent or push message URIs for the same subscription MUST NOT include any information that allows them to be correlated with the user agent. </ins> This need not be perfect as long as the resulting anonymity set (see RFC6973, Section 6.1.1) is sufficiently large.  A "push" URI Authorization for subscriptions is managed using "subscription" and "push" capability URLs (see CAP-URI).  A capability URL grants access  <ins> to a resource based solely on knowledge of the URL. Capability URLs are used for their "easy onward sharing" and "easy client API" properties.  These make it possible to avoid relying on relationships between push services and application servers, with the protocols necessary to build and support those relationships. </ins>  <ins> A "subscription", "push" or push message URI therefore acts as a bearer token.  Knowledge of a "subscription" URI implies authorization to either receive push messages or delete the subscription.  Knowledge of a "push" URI implies authorization to send push messages.  Knowledge of a push message URI allows for reading that specific message. </ins> Encoding a large amount of random entropy (at least 120 bits) in the path component ensures that it is difficult to successfully guess a  <ins> valid capability URL. </ins> 7.4. a "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  <ins> subscription-related URIs for the same user agent.  Encrypted message contents are not revealed to the push service. </ins> Limitations on log retention and strong access control mechanisms can ensure that URIs are not learned by unauthorized entities.


The push service MUST use HTTP over TLS [RFC2818] following the recommendations in [RFC7525].  The push service shares the same default port number (443/TCP) with HTTPS, but MAY also advertise the <del> IANA allocated TCP System Port 1001 using HTTP alternative services RFC7838. </del>  While the default port (443) offers broad reachability characteristics, it is most often used for web browsing scenarios For webpush scenarios, this would contribute to unnecessary radio communications to maintain the connection on battery-powered devices. <del> Advertising the alternate port (1001) allows middleboxes to optimize idle timeouts for connections specific to push scenarios with the expectation that data exchange will be infrequent. </del>  Middleboxes SHOULD comply with REQ-5 in RFC5382 which requires that "the value of the 'established connection idle-timeout' MUST NOT be <https://www.iana.org/assignments/service-names-port-numbers/service- names-port-numbers.xhtml>. <del> IANA is requested to assign the System Port number 1001 and the service name "webpush" in accordance with RFC6335. </del>  webpush 1001

Based on the IANA review: Update IANA Considerations to indicate the System Port 1001 is a suggestion Update inline references to 1001 to "TBD"
LGTM (I'll let you merge this one).

The push service MUST use HTTP over TLS [RFC2818] following the recommendations in [RFC7525].  The push service shares the same default port number (443/TCP) with HTTPS, but MAY also advertise the  <ins> IANA allocated TCP System Port (WEBPUSH-PORT) using HTTP alternative services RFC7838. </ins> While the default port (443) offers broad reachability characteristics, it is most often used for web browsing scenarios For webpush scenarios, this would contribute to unnecessary radio communications to maintain the connection on battery-powered devices.  <ins> Advertising the alternate port (WEBPUSH-PORT) allows middleboxes to optimize idle timeouts for connections specific to push scenarios with the expectation that data exchange will be infrequent. </ins> Middleboxes SHOULD comply with REQ-5 in RFC5382 which requires that "the value of the 'established connection idle-timeout' MUST NOT be <https://www.iana.org/assignments/service-names-port-numbers/service- names-port-numbers.xhtml>.  <ins> In accordance with RFC6335, it is requested that IANA assign the suggested System Port number 1001 (or another port in the System range) and the service name "webpush". </ins> webpush 1001 <ins> [[The RFC Editor is requested to remove this editorial note at publication.]] This document uses a placeholder value for a system port pending IANA assignment which needs to be replaced with the finalized value at the time of publication.  Please apply the following replacement: "WEBPUSH-PORT" --> the assigned port value for "webpush" </ins>


provides confidentiality and integrity protection for subscriptions and push messages from external parties. <del> Applications using this protocol MUST use mechanisms that provide confidentiality, integrity and data origin authentication.  The application server sending the push message and the application on the user agent that receives it are frequently just different instances of the same application, so no standardized protocol is needed to establish a proper security context.  The distribution of subscription information from the user agent to its application server also offers a convenient medium for key agreement. </del> 8.1. The protection afforded by TLS does not protect content from the push service.  Without additional safeguards, a push service can inspect and modify the message content. <del> For its requirements, the API has adopted I-D.ietf-webpush-encryption </del>  to secure the content of messages from the push service.  Other scenarios can be addressed by similar policies.

Ben commented in his review that the requirement for confidentiality seemed to be covered by TLS, unless the text was actually referring to e2e protections (which I believe that it was). Moving the paragraph from the introduction of S8 to the immediate subsection resolves this confusion.

provides confidentiality and integrity protection for subscriptions and push messages from external parties.  8.1. The protection afforded by TLS does not protect content from the push service.  Without additional safeguards, a push service can inspect and modify the message content.  <ins> Applications using this protocol MUST use mechanisms that provide end-to-end confidentiality, integrity and data origin authentication. The application server sending the push message and the application on the user agent that receives it are frequently just different instances of the same application, so no standardized protocol is needed to establish a proper security context.  The distribution of subscription information from the user agent to its application server also offers a convenient medium for key agreement. For this requirement, the API has adopted I-D.ietf-webpush-encryption </ins> to secure the content of messages from the push service.  Other scenarios can be addressed by similar policies.


A user agent sends a POST request to its configured push service resource to create a new subscription. <del> A 201 (Created) response indicates that the a push subscription was </del>  created.  A URI for the push message subscription resource that was created in response to the request MUST be returned in the Location header field. A push service that does not support reliable delivery over intermittent network connections or failing applications on devices, forces the device to acknowledge receipt directly to the application <del> server, incurring additional power drain in order to establish (usually secure) connections to the individual application servers. </del>  Push message reliability can be important if messages contain information critical to the state of an application.  Repairing state

This is the initial update for the Spencer Dawkins review. I'll wait to see if there are additional comments to address before merging. Editorial update to Section 7.4 Also fixed a the a nit.
Merging per Spencer's response.

A user agent sends a POST request to its configured push service resource to create a new subscription.  <ins> A 201 (Created) response indicates that the push subscription was </ins> created.  A URI for the push message subscription resource that was created in response to the request MUST be returned in the Location header field. A push service that does not support reliable delivery over intermittent network connections or failing applications on devices, forces the device to acknowledge receipt directly to the application  <ins> server, incurring additional power drain in order to establish and maintain (usually secure) connections to the individual application servers. </ins> Push message reliability can be important if messages contain information critical to the state of an application.  Repairing state


field contains a value in seconds that describes how long a push message is retained by the push service. <del> Once the Time-To-Live (TTL) period elapses, the push service MUST remove the push message and cease any attempt to deliver it to the user agent.  A push service might retain values for a short duration after the TTL period to account for time accounting errors in processing.  For instance, distributing a push message within a server cluster might accrue errors due to clock variation, or processing and transit delays. </del>  A push service is not obligated to account for time spent by the application server in sending a push message to the push service, or TTL header field value. Absence of the TTL header field is interpreted as equivalent to a <del> zero value.  Push messages with a zero TTL indicate that storage is not needed and that the message can be dropped if the user agent isn't immediately available to receive the message.  Push messages with a zero TTL can be delivered very efficiently. </del>  A push service MAY choose to retain a push message for a shorter duration than that requested.  It indicates this by including a TTL

NAME clarification on TTL of 0: The spec indicates a TTL of 0 should result in the message not being delivered if the client is not connected. However, it doesn't indicate whether the Push server is still under the same obligation to provide a Location header in the response in this case (I assume its still a 201, even though a resource was not created?). Should a Location still be returned? What kind of receipt is assumed in this case (or no receipt and no Location)?
NAME notes that the requirement to delete immediately after TTL expires (or at least soon after) is not compatible with certain push service implementation strategies. We should allow for these designs. Since the data is encrypted, the implications of retention are less, but we should probably still require some upper bound on this time.
As by NAME the spec should certainly require that expired messages are not delivered, but not how it is implemented. Best time bound would be 'maximum TTL' - it's cheapest in some databases.
Tracking Darshak Thakore feedback. There's some confusion about the relationship between UA acknowledgements and AS receipts. For example: If stuff in Section 4 and Section 6.2 does not happen, can the interaction between the UA and the PS be simplified (the PS can itself delete the push message resource) The draft should clarify the scenarios motivating the feature and discuss appropriate behavior in the face of acknowledgement failures. There were more details about the motivation in the Introduction of URL : A push server that does not support reliable delivery over intermittent network connections or failing applications on devices, forces the device to acknowledge receipt directly to the application server, incurring additional power drain in order to establish (usually secure) connections to the individual application servers. While reliability is not required for messages that expire in few seconds (e.g. an incoming call) or collapsible ones (e.g. the current number of unread emails), it is more important when messages contain information that is longer lasting, e.g. a command to update a configuration value, or the acknowledgement of a financial transaction or workflow step. In particular, in the case of power- constrained devices, it is preferable to transmit the actual information in the "pushed" message reliably, instead of forcing them to reconnect periodically to get the current state.
I believe that this was addressed in the previous set of editorial changes - . Please re-open if further clarifications are required. GCM is doing lazy cleanup - and checks before delivering any message. The cost to delete each expired message at the time it expired would be quite big - the spec should certainly require that expired messages are not delivered, but not how it is implemented. Best time bound would be 'maximum TTL' - it's cheapest in some databases. Costin , Martin Thomson wrote: >
The spec indicates a TTL of 0 should result in the message not being delivered if the client is not connected. However, it doesn't indicate whether the Push server is still under the same obligation to provide a Location header in the response in this case (I assume its still a 201, even though a resource was not created?). Should a Location still be returned? What kind of receipt is assumed in this case (or no receipt and no Location)? Cheers, Ben

field contains a value in seconds that describes how long a push message is retained by the push service.  <ins> Once the Time-To-Live (TTL) period elapses, the push service MUST NOT attempt to deliver the push message to the user agent.  A push service might adjust the TTL value to account for time accounting errors in processing.  For instance, distributing a push message within a server cluster might accrue errors due to clock skew or propagation delays. </ins> A push service is not obligated to account for time spent by the application server in sending a push message to the push service, or TTL header field value. Absence of the TTL header field is interpreted as equivalent to a  <ins> zero value.  A Push message with a zero TTL is immediately delivered if the user agent is available to receive the message.  After delivery, the push service is permitted to immediately remove a push message with a zero TTL.  This might occur before the user agent acknowledges receipt of the message by performing a HTTP DELETE on the push message resource.  Consequently, an application server cannot rely on receiving acknowledgement receipts for zero TTL push messages. If the user agent is unavailable, a push message with a zero TTL expires and is never delivered. </ins> A push service MAY choose to retain a push message for a shorter duration than that requested.  It indicates this by including a TTL


In response to this request, the push server MUST generate a server push for all push messages that have not yet been delivered.  In addition, the push service SHOULD return link references to the push <del> and receipt subscribe resources, plus expiration information for the subscription. </del>  A user agent can request the contents of the push message subscription resource immediately by including a RFC7240 with a they can be refreshed.  This applies to both push message subscriptions and receipt subscriptions. <del> A push service might choose to set a fixed expiration time.  If a resource has a known expiration time, expiration information is included in responses to requests that create the resource, or in requests that retrieve a representation of the resource. Expiration is indicated using either the Expires header field, or by setting a "max-age" parameter on a Cache-Control header field (see RFC7234).  The Cache-Control header field MUST also include the "private" directive. </del> A push service can remove a subscription at any time.  If a user agent or application server has an outstanding request to a subscription resource (see monitor), this can be signaled by

Removed references to HTTP cache headers and RFC7234
LGTM
Tracking Darshak Thakore feedback: There was ambiguity about the type of "expiration information" returned: Also I'm assuming here that the "expiration information" refers to the expiration info of the push messages (i.e their TTL), correct? NAME has added a small clarification: URL but an example should be developed.
As discussed on the , the use of HTTP cache headers for graceful subscription expiration was deprecated. Our implementation is currently only reactive when it comes to subscription expiration. That means that we tolerate a break if the server is forced to expire a subscription. Note that the discussion from before was all predicated on a different design, one where individual subscriptions were subjugate to a larger "registration". The current design, even the with the addition of subscription sets, doesn't suffer from the ambiguity problem you described. However, after reviewing the HTTP cache control stuff in more detail, I think that it might be best to remove this feature. The use case (graceful replacement of a subscription), might be important, but I don't think that using response freshness as a proxy for subscription lifetime is correct. If we discover that there is a need, I think that an alternative mechanism will be required. A more direct signal an explicit "refresh now" message - might be a superior option. The consequence of that is that we will rely on the 4xx responses to inform user agents of when the push service has expired a subscription. For the moment, that's probably OK. The consequential drop in reliability should be low.

In response to this request, the push server MUST generate a server push for all push messages that have not yet been delivered.  In addition, the push service SHOULD return link references to the push  <ins> and receipt subscribe resources. </ins> A user agent can request the contents of the push message subscription resource immediately by including a RFC7240 with a they can be refreshed.  This applies to both push message subscriptions and receipt subscriptions.  A push service can remove a subscription at any time.  If a user agent or application server has an outstanding request to a subscription resource (see monitor), this can be signaled by