One document matched: draft-thomson-webpush-encryption-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.20 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<rfc ipr="trust200902" docName="draft-thomson-webpush-encryption-01" category="std">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<front>
<title abbrev="Web Push Encryption">Message Encryption for Web Push</title>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Mozilla</organization>
<address>
<email>martin.thomson@gmail.com</email>
</address>
</author>
<date year="2015"/>
<abstract>
<t>A message encryption scheme is described for the Web Push protocol. This scheme
provides confidentiality and integrity for messages sent from an Application
Server to a User Agent.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>The Web Push protocol <xref target="I-D.thomson-webpush-protocol"></xref> is an intermediated
protocol by necessity. Messages from an Application Server are delivered to a
User Agent via a Push Service.</t>
<figure><artwork><![CDATA[
+-------+ +--------------+ +-------------+
| UA | | Push Service | | Application |
+-------+ +--------------+ +-------------+
| | |
| Setup | |
|<====================>| |
| Provide Subscription |
|-------------------------------------------->|
| | |
: : :
| | Push Message |
| Push Message |<---------------------|
|<---------------------| |
| | |
]]></artwork></figure>
<t>This document describes how messages sent using this protocol can be secured
against inspection or modification by a Push Service.</t>
<t>Web Push messages are the payload of an HTTP message <xref target="RFC7230"></xref>. These messages
are encrypted using an encrypted content encoding
<xref target="I-D.thomson-http-encryption"></xref>. This document describes how this
content encoding is applied and describes a recommended key management scheme.</t>
<t>For efficiency reasons, multiple users of Web Push often share a central agent
that aggregates push functionality. This agent can enforce the use of this
encryption scheme by applications that use push messaging. An agent that only
delivers messages that are properly encrypted strongly encourages the end-to-end
protection of messages.</t>
<t>A web browser that implements the Web Push API <xref target="API"></xref> can enforce the use of
encryption by forwarding only those messages that were properly encrypted.</t>
<section anchor="notational-conventions" title="Notational Conventions">
<t>The words “MUST”, “MUST NOT”, “SHOULD”, and “MAY” are used in this document.
It’s not shouting, when they are capitalized, they have the special meaning
described in <xref target="RFC2119"></xref>.</t>
</section>
</section>
<section anchor="key-generation-and-agreement" title="Key Generation and Agreement">
<t>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) <xref target="DH"></xref> or
elliptic-curve Diffie-Hellman (ECDH) <xref target="ECDH"></xref>. 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.</t>
<t>This key pair is used with the Diffie-Hellman key exchange as described in
Section 4.2 of <xref target="I-D.thomson-http-encryption"></xref>.</t>
<t>A User Agent MUST generate and provide a public key for the scheme described in
<xref target="mti"/>.</t>
<t>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.</t>
<section anchor="diffie-hellman-group-information" title="Diffie-Hellman Group Information">
<t>As described in <xref target="I-D.thomson-http-encryption"></xref>, use of Diffie-Hellman
for key agreement requires that the receiver provide clear information about
it’s chosen group and the format for the “dh” parameter with each potential
sender.</t>
<t>This document only describes a single ECDH group and point format, described in
<xref target="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.</t>
</section>
<section anchor="key-distribution" title="Key Distribution">
<t>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.</t>
<t>The communication medium by which an application distributes the key identifier
and public key MUST be confidentiality protected for the reasons described in
<xref target="I-D.thomson-webpush-protocol"></xref>. 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 <xref target="RFC2818"></xref>, is sufficient.</t>
</section>
</section>
<section anchor="message-encryption" title="Message Encryption">
<t>An Application Server that has the key identifier, public key, group and format
information can encrypt a message for the User Agent.</t>
<t>The Application Server generates a new DH or ECDH key pair in the same group as
the value generated by the User Agent.</t>
<t>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 <xref target="RFC4086"></xref> salt is acceptable. These values are used
to calculate the content encryption key as defined in Section 3.2 of
<xref target="I-D.thomson-http-encryption"></xref>.</t>
<t>The Application Server then encrypts the payload. Header fields are populated
with URL-safe base-64 encoded <xref target="RFC4648"></xref> values:</t>
<t><list style="symbols">
<t>the “keyid” from the User Agent is added to both the Encryption-Key and
Encryption header fields;</t>
<t>the salt is added to the “salt” parameter of the Encryption header field; and</t>
<t>the public key for its DH or ECDH key pair is placed in the “dh” parameter of
the Encryption-Key header field.</t>
</list></t>
<t>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 <spanx style="verb">rs</spanx> parameter
MUST be set to a value that is longer than the encrypted push message length.</t>
<t>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 the <spanx style="verb">rs</spanx> parameter
can be omitted for messages that fit within this limit.</t>
</section>
<section anchor="message-decryption" title="Message Decryption">
<t>A User Agent decrypts messages are decrypted as described in
<xref target="I-D.thomson-http-encryption"></xref>. 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.</t>
<t>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 <spanx style="verb">rs</spanx> 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.</t>
</section>
<section anchor="mti" title="Mandatory Group and Public Key Format">
<t>User Agents that enforce encryption MUST expose an elliptic curve Diffie-Hellman
share on the P-256 curve <xref target="FIPS186"></xref>. Public keys, such as are encoded into the
“dh” parameter, MUST be in the form of an uncompressed point as described in
<xref target="X.692"></xref>.</t>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>This document has no IANA actions.</t>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>The security considerations of <xref target="I-D.thomson-http-encryption"></xref>
describe the limitations of the content encoding. In particular, any HTTP
header fields are not protected by the content encoding scheme. A User Agent
MUST consider HTTP header fields to have come from the Push Service. An
application on the User Agent that uses information from header fields to alter
their processing of a push message is exposed to a risk of attack by the Push
Service.</t>
<t>The timing and length of communication cannot be hidden from the Push Service.
While an outside observer might see individual messages intermixed with each
other, the Push Service will see what Application Server is talking to which
User Agent, and the subscription they are talking about. Additionally, the
length of messages could be revealed unless the padding provided by the content
encoding scheme is used to obscure length.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='I-D.thomson-webpush-protocol'>
<front>
<title>Generic Event Delivery Using HTTP Push</title>
<author initials='M' surname='Thomson' fullname='Martin Thomson'>
<organization />
</author>
<author initials='E' surname='Damaggio' fullname='Elio Damaggio'>
<organization />
</author>
<author initials='B' surname='Raymor' fullname='Brian Raymor'>
<organization />
</author>
<date month='April' day='15' year='2015' />
<abstract><t>A simple protocol for the delivery of realtime events to user agents is described. This scheme uses HTTP/2 server push.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-thomson-webpush-protocol-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-thomson-webpush-protocol-00.txt' />
<format type='PDF'
target='http://www.ietf.org/internet-drafts/draft-thomson-webpush-protocol-00.pdf' />
</reference>
<reference anchor='I-D.thomson-http-encryption'>
<front>
<title>Encrypted Content-Encoding for HTTP</title>
<author initials='M' surname='Thomson' fullname='Martin Thomson'>
<organization />
</author>
<date month='July' day='1' year='2015' />
<abstract><t>This memo introduces a content-coding for HTTP that allows message payloads to be encrypted.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-thomson-http-encryption-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-thomson-http-encryption-01.txt' />
</reference>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17970' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<reference anchor='RFC4086'>
<front>
<title>Randomness Requirements for Security</title>
<author initials='D.' surname='Eastlake' fullname='D. Eastlake'>
<organization /></author>
<author initials='J.' surname='Schiller' fullname='J. Schiller'>
<organization /></author>
<author initials='S.' surname='Crocker' fullname='S. Crocker'>
<organization /></author>
<date year='2005' month='June' />
<abstract>
<t>Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t><t> Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front>
<seriesInfo name='BCP' value='106' />
<seriesInfo name='RFC' value='4086' />
<format type='TXT' octets='114321' target='http://www.rfc-editor.org/rfc/rfc4086.txt' />
</reference>
<reference anchor="DH" >
<front>
<title>New Directions in Cryptography</title>
<author initials="W." surname="Diffie">
<organization></organization>
</author>
<author initials="M." surname="Hellman">
<organization></organization>
</author>
<date year="1977" month="June"/>
</front>
<seriesInfo name="IEEE Transactions on Information Theory, V.IT-22 n.6" value=""/>
</reference>
<reference anchor="ECDH" target="http://www.secg.org/">
<front>
<title>Elliptic Curve Cryptography</title>
<author >
<organization>SECG</organization>
</author>
<date year="2000"/>
</front>
<seriesInfo name="SEC 1" value=""/>
</reference>
<reference anchor="FIPS186" >
<front>
<title>Digital Signature Standard (DSS)</title>
<author >
<organization>National Institute of Standards and Technology (NIST)</organization>
</author>
<date year="2013" month="July"/>
</front>
<seriesInfo name="NIST PUB 186-4" value=""/>
</reference>
<reference anchor="X.692" >
<front>
<title>Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
<author >
<organization>ANSI</organization>
</author>
<date year="1998"/>
</front>
<seriesInfo name="ANSI X9.62" value=""/>
</reference>
</references>
<references title='Informative References'>
<reference anchor='RFC2818'>
<front>
<title>HTTP Over TLS</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<date year='2000' month='May' />
<abstract>
<t>This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='2818' />
<format type='TXT' octets='15170' target='http://www.rfc-editor.org/rfc/rfc2818.txt' />
</reference>
<reference anchor='RFC4648'>
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author initials='S.' surname='Josefsson' fullname='S. Josefsson'>
<organization /></author>
<date year='2006' month='October' />
<abstract>
<t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4648' />
<format type='TXT' octets='35491' target='http://www.rfc-editor.org/rfc/rfc4648.txt' />
</reference>
<reference anchor='RFC7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding'>
<organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke'>
<organization /></author>
<date year='2014' month='June' />
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract></front>
<seriesInfo name='RFC' value='7230' />
<format type='TXT' octets='205947' target='http://www.rfc-editor.org/rfc/rfc7230.txt' />
</reference>
<reference anchor="API" target="https://w3c.github.io/push-api/">
<front>
<title>Web Push API</title>
<author initials="B." surname="Sullivan">
<organization></organization>
</author>
<author initials="E." surname="Fullea">
<organization></organization>
</author>
<author initials="M." surname="van Ouwerkerk">
<organization></organization>
</author>
<date year="2015"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:05:01 |