Draft: draft-ietf-webpush-encryption

Commentary:   and   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 ca n'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 wo n't leak bits of the public key . For instance , if an implementation is n'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 does n'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 
 Updated to be based on martinthomson / http - encryption based on
This document describes how messages sent using this protocol can be
secured against inspection or modification by a Push Service.
This document describes how messages sent using this protocol can be
secured against inspection, modification and falsification by a Push
Service.
An Application Server that has the key identifier, public key, group
and format information can encrypt a message for 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
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.
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.
An Application Server that has the public key, group and format
information plus the authentication secret can encrypt a message for
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
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.
the public key for its DH or ECDH key pair is placed in the "dh"
parameter of the Encryption-Key header field.
An application server MUST encrypt a push message with a single
record.  This allows for a minimal receiver implementation that
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.
the public key for its DH or ECDH key pair is placed in the "dh"
parameter of the Crypto-Key header field.
An application server MUST encrypt a push message with a single
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.
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.
A User Agent decrypts messages are decrypted as described in I-
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.
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.
An application server MUST NOT include an "aesgcm128" parameter in
the Encryption header field.
A User Agent decrypts messages are decrypted as described in I-
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.
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.
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).