Original text:
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.

Reviewer comments:
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

Revised text:
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.