Change:
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. <del> An Application Server that has the key identifier, public key, group and format information can encrypt a message for the User Agent. </del> <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 <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> <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:

Discussion:
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