Network Working Group P. Hallam-Baker Internet-Draft Comodo Group Inc. Intended status: Informational August 22, 2016 Expires: February 23, 2017 Mesh/Recrypt A New Approach to Messaging draft-hallambaker-mesh-recrypt-00 Abstract A messaging infrastructure providing full end-to end security is presented. Unlike existing approaches such as S/MIME and OpenPGP, Mesh/Recrypt uses proxy re-encryption to preserve full end-to-end security with individual user and device keys in situations such as the user having multiple decryption devices and messages being set to mailing lists. This document shows the use of Mesh/Recrypt to address the principle use cases Mesh/Recrypt is designed to address. These include asynchronous messaging such as mail and controlled documents and synchronous messaging applications such as chat, voice and video. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 23, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Hallam-Baker Expires February 23, 2017 [Page 1] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2.2. Related Specifications . . . . . . . . . . . . . . . . . 5 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 3. Proxy Re-Encryption . . . . . . . . . . . . . . . . . . . . . 7 3.1. Proxy Re-Encryption Algorithms . . . . . . . . . . . . . 8 3.2. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Chat rooms and other streaming data. . . . . . . . . . . 11 3.4. Confidential Document Control . . . . . . . . . . . . . . 11 3.5. Multiple Devices . . . . . . . . . . . . . . . . . . . . 12 4. Mesh/Recrypt . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Parties create a Mesh personal profile . . . . . . . . . 14 4.3. Alice creates a recryption group . . . . . . . . . . . . 15 4.4. Alice encrypts a document . . . . . . . . . . . . . . . . 15 4.5. Alice adds Bob and Carol to the recryption group . . . . 16 4.6. Bob decrypts a document . . . . . . . . . . . . . . . . . 17 4.7. Bob uses multiple devices . . . . . . . . . . . . . . . . 18 4.8. Alice revokes Carol's group membership . . . . . . . . . 19 4.9. Bob loses a device . . . . . . . . . . . . . . . . . . . 19 4.10. Bob visits a hostile environment . . . . . . . . . . . . 19 5. Recrypt Service Reference . . . . . . . . . . . . . . . . . . 19 5.1. Request Messages . . . . . . . . . . . . . . . . . . . . 20 5.1.1. Message: RecryptRequest . . . . . . . . . . . . . . . 20 5.2. Response Messages . . . . . . . . . . . . . . . . . . . . 20 5.2.1. Message: RecryptResponse . . . . . . . . . . . . . . 20 5.2.2. Successful Response Codes . . . . . . . . . . . . . . 21 5.2.3. Warning Response Codes . . . . . . . . . . . . . . . 21 5.2.4. Error Response Codes . . . . . . . . . . . . . . . . 22 5.2.5. Failure Response Codes . . . . . . . . . . . . . . . 22 5.3. Imported Objects . . . . . . . . . . . . . . . . . . . . 23 5.4. Common Structures . . . . . . . . . . . . . . . . . . . . 23 5.4.1. Structure: Version . . . . . . . . . . . . . . . . . 23 5.4.2. Structure: Encoding . . . . . . . . . . . . . . . . . 23 5.4.3. Structure: Resource . . . . . . . . . . . . . . . . . 24 5.4.4. Structure: Static . . . . . . . . . . . . . . . . . . 24 5.4.5. Structure: Dynamic . . . . . . . . . . . . . . . . . 24 5.4.6. Structure: ResourceSet . . . . . . . . . . . . . . . 24 Hallam-Baker Expires February 23, 2017 [Page 2] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 5.4.7. Structure: User . . . . . . . . . . . . . . . . . . . 24 5.4.8. Structure: Label . . . . . . . . . . . . . . . . . . 25 5.4.9. Structure: KeySet . . . . . . . . . . . . . . . . . . 25 5.5. Transaction: Hello . . . . . . . . . . . . . . . . . . . 25 5.5.1. Message: HelloRequest . . . . . . . . . . . . . . . . 25 5.5.2. Message: HelloResponse . . . . . . . . . . . . . . . 25 5.6. Transaction: Set . . . . . . . . . . . . . . . . . . . . 26 5.6.1. Message: SetRequest . . . . . . . . . . . . . . . . . 26 5.6.2. Message: SetResponse . . . . . . . . . . . . . . . . 26 5.7. Transaction: Get . . . . . . . . . . . . . . . . . . . . 26 5.7.1. Message: GetRequest . . . . . . . . . . . . . . . . . 26 5.7.2. Message: GetResponse . . . . . . . . . . . . . . . . 27 5.8. Transaction: Delete . . . . . . . . . . . . . . . . . . . 27 5.8.1. Message: DeleteRequest . . . . . . . . . . . . . . . 27 5.8.2. Message: DeleteResponse . . . . . . . . . . . . . . . 27 5.9. Transaction: Select . . . . . . . . . . . . . . . . . . . 27 5.9.1. Message: SearchRequest . . . . . . . . . . . . . . . 27 5.9.2. Message: SearchResponse . . . . . . . . . . . . . . . 28 5.10. Transaction: Join . . . . . . . . . . . . . . . . . . . . 28 5.10.1. Message: JoinRequest . . . . . . . . . . . . . . . . 28 5.10.2. Message: JoinResponse . . . . . . . . . . . . . . . 28 5.11. Transaction: Leave . . . . . . . . . . . . . . . . . . . 28 5.11.1. Message: LeaveRequest . . . . . . . . . . . . . . . 28 5.11.2. Message: LeaveResponse . . . . . . . . . . . . . . . 29 6. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1. Payment Integration . . . . . . . . . . . . . . . . . . . 29 6.2. Contact Management . . . . . . . . . . . . . . . . . . . 29 6.3. SMTP, IMAP and POP3 Integration . . . . . . . . . . . . . 29 6.4. S/MIME Extensions . . . . . . . . . . . . . . . . . . . . 29 6.5. OpenPGP Extensions . . . . . . . . . . . . . . . . . . . 29 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 29 8.1. Reference Implementation . . . . . . . . . . . . . . . . 30 8.1.1. Coverage: . . . . . . . . . . . . . . . . . . . . . . 30 8.1.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 30 8.1.3. Implementation Experience . . . . . . . . . . . . . . 31 8.1.4. Contact Info . . . . . . . . . . . . . . . . . . . . 31 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . 31 11.2. Informative References . . . . . . . . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32 Hallam-Baker Expires February 23, 2017 [Page 3] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 1. Introduction Traditional messaging security infrastructures are difficult to configure, difficult to use and limited to one mode of communication. Digital certificates are hard to obtain and harder to maintain. Managing a Web of Trust requires a very high level of user competence. S/MIME and OpenPGP offer end-to-end email security but not streaming services such as video, voice or chat. In recent years a number of proprietary chat systems have been extended to the point that a single application and protocol supports chat, voice, video and asynchronous communication modes such as messaging and file transfer. While such systems typically claim to offer cryptographic security, the extent to which this is achieved is difficult to determine. Even systems purporting to offer 'end-to- end' security have proved to be woefully inadequate when it is discovered that one of the 'ends' referred to is in fact the messaging infrastructure operated by the provider. A key limitation of all the deployed messaging systems that were reviewed in the development of this paper is that true end-to-end confidentiality is only achieved for a limited set of communication patterns. Specifically, bilateral communications (Alice sends a message to Bob) or broadcast communications to a known set of recipients (Alice sends a message to Bob, Carol and Doug). These capabilities do not support communication patterns where the set of recipients changes over time or is confidential. Yet such requirements commonly occur in situations such as sending a message to a mailing list whose membership isn't known to the sender, or creating a spreadsheet whose readership is to be limited to authorized members of the 'accounting' team. Mesh/Recrypt is an experimental messaging infrastructure that applies proxy re-encryption to support all the commonly used messaging modes with strong end-to-end encryption. The primary purpose of Mesh/ Recrypt is to demonstrate the advantages of using the proxy re- encryption technique and to determine the feasibility of retrofitting such capabilities to legacy protocols such as SMTP, IMAP and XMPP. Whether the advantages of building on an established base outweigh those of a clean slate approach for purposes of deployment are currently unknown, but there are clear advantages of using a clean slate approach for purposes of exposition. As the name suggests, Mesh/Recrypt makes use of the Mathematical Mesh infrastructure for management of user keys. For clarity and convenience, this document describes the application of Mesh/Remesh to a completely new protocol suite. Strategies for adding similar Hallam-Baker Expires February 23, 2017 [Page 4] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 capabilities to existing specifications are discussed as possible future work. 2. Definitions [Please note that due to work in progress to support the new RFC format etc, some of the formatting features are not currently working as they should. These will be fixed in a future version.] 2.1. Requirements Language 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 [RFC2119]. 2.2. Related Specifications This protocol is makes use of technology described in the following specifications JSON [RFC7159] For encoding of message data structures. JOSE [RFC7515] [RFC7516] [RFC7518] Formats for cryptographic messages and keys in JSON. JSON Web Service [draft-hallambaker-json-web-service-02] Describes the approach used for Web Service discovery and the encapsulation of JSON messages as HTTP payloads with the necessary authentication and encryption services. Uniform Data Fingerprint [draft-hallambaker-udf-03] Describes the mechanism used to create identifiers for cryptographic keypairs from the public key. In addition, the following specifications are closely related but not required for implementation: Transport Layer Security [RFC5246] The use of TLS to protect the confidentiality and integrity of all protocol communications is of course highly recommended. It is however highly undesirable for a cryptographic protocol such as LURK should rely on transport layer security enhancements alone. Hallam-Baker Expires February 23, 2017 [Page 5] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 The Mathematical Mesh [draft-hallambaker-mesh-architecture-01] [draft-hallambaker-mesh-reference-02] MAY be used to establish trust relationships between the parties in the protocol. CFRG Elliptic Curves and Algorithms [RFC7748] The threshold and proxy re-encryption schemes described are likely to be of most interest in conjunction with the emerging elliptic curve based cryptography. JSON-BCD [draft-hallambaker-jsonbcd-05] JSON-B or JSON-C encoding may be used if an efficient binary or compressed encoding is required. Alternatively, message structures MAY be encoded according to TLS conventions. 2.3. Terminology The following terms are used as terms of art in this document with the meaning specified below: Confidential Document Control (CDC) An Access Control mechanism that uses cryptography to control read access to static content (typically documents) within its control. Controlled Document Content that is subject to control of a CDC system. Proxy Re-Encryption A cryptography mechanism that permits a party that does not have the ability to decrypt an encrypted message to transform it into a message that can be decrypted under a different private key than the original. Recryption The term 'recryption' is used as a synonym for Proxy Re-Encryption in this document. Recryption Key Hallam-Baker Expires February 23, 2017 [Page 6] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 A cryptographic key that is used to enable a different party to decrypt an encrypted message that does not grant decryption capability. 3. Proxy Re-Encryption Proxy re-encryption provides a technical capability that meets the needs of such communication patterns. Conventional symmetric key cryptography uses a single key to encrypt and decrypt data. Public key cryptography uses two keys, the key used to encrypt data is separate from the key used to decrypt. Proxy re-encryption introduces a third key (the recryption key) that allows a party to permit an encrypted data packet to be decrypted using a different key without permitting the data to be decrypted. The introduction of a recryption key permits end-to-end confidentiality to be preserved when a communication pattern requires that some part of the communication be supported by a service. The introduction of a third type of key, the recryption key permits a two new roles to be established, that of an administrator and recryption service. There are thus four roles: Administrator Holder of Decryption Key, Creator of Recryption Keys Sender Holder of Encryption Key Recryption Service Holder of Recryption keys Receiver Holder of personal decryption key The chief advantage of recryption is that the recryption service does not have the ability to decrypt messages and does not need to be trusted at the same level as a recipient. A recryption service may be implemented as a cloud service on an untrusted host or managed in house by a system administrator who is only partially trusted. Hallam-Baker Expires February 23, 2017 [Page 7] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 3.1. Proxy Re-Encryption Algorithms Proxy Re-Encryption was introduced by Blaze et. al. [Blaze] in 1998. In this paper we make use of the Diffie Hellman based mechanism described in this paper. While this approach does not have capabilities such as reversibility or transitivity offered in later work, such features do not appear to offer any practical advantages in developing protocols for the intended applications and may well introduce significant disadvantages. The use of the Diffie Hellman based approach has the considerable advantages of being compatible with the recently developed CFRG Elliptic Curve algorithms and being minimally unencumbered by IPR claims. Recall that in the Diffie Hellman key agreement algorithm, shared parameters e and p are generated, these being an exponent value (e) and a modulus value (p). To create a shared key, two parties (Alice and Bob) generate private keys a, b being positive integers in the interval [2 ... p-1]. The corresponding public keys are then e^a mod p and e^b mod p. Thus knowledge of either {e^b mod p, a} or {e^a mod p, b} is sufficient to calculate the shared secret value s = e^ab mod p. When applying Diffie Hellman to a messaging protocol, it is typically desirable to ensure that a unique shared value is created for each exchange. If the protocol only requires authentication of the receiver, the sender may ensure that each shared value is unique by generating a new key pair {t, e^t mod p} for each exchange. Alternatively, mutual authentication may be preserved if the shared secret is formed from three values s = e^abt mod p, where a and b are the validated public keys of the sender and receiver and t is a temporary key generated by the sender that has a nonce-like function. To adapt Diffie Hellman to a recryption mechanism, we note that just as the value s = e^at mod p may be calculated as either (e^a mod p)^t mod p or (e^t mod p)^a mod p, it can also be calculated as ((e^t mod p)^a-x mod p . (e^t mod p)^x mod p) mod p. We may apply this equivalence to create a recryption scheme. In the following example, Alice is the administrator of the recryption group and Bob and Carol are recipients. Bob Generates a public key encryption pair (b, B). The algorithm used for this does not matter, as the only functions used are encryption and decryption. Hallam-Baker Expires February 23, 2017 [Page 8] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 Bob publishes his public key B. Alice (Administrator) Generates public key pair {a, e^a mod p}. Publishes the public key value for the recryption group e^a mod p To enable Bob to receive messages, Alice generates a recryption keypair for Bob {a-bx, bx} and encrypts the decryption key (bx) using Bob's public key (B) to create a recryption entry for Bob {a-bx, E(bx, B)}. The recryption entry is sent to the recryption service. Carol (Sender) Generates a temporary key pair {t, e^t mod p} and uses this and the public key of the recryption group (e^a mod p) to create a shared secret s = e^at mod p that is used to encrypt the message. Sends the encrypted message and temporary public key (e^t mod p) to the recryption service Recryption Service Receives the message and retrieves the list of intended recipients, this currently has just a single entry for Bob {a-bx, E(bx, B)} Calculates (e^t mod p)^(a-bx) mod p = e^(ta-tbx) mod p Sends the encrypted message, the original temporary public key generated by Carol (e^t mod p), the recryption value e^(ta-tbx) mod p and the encrypted decryption key E(bx, B) to Bob. Bob Receives the message Decrypts the E(bx, B) using his private key b to obtain bx Uses bx and e^t mod p to calculate e^(tbx) mod p Calculates (e^(ta-tbx) mod p. e^(tbx) mod p) mod p = e^ta mod p = s Uses s to decrypt the message Hallam-Baker Expires February 23, 2017 [Page 9] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 One particular advantage of using recryption is that the administrator does not need to be online during the message transfer. Administrator actions are only required when adding or removing recipients. Another advantage of recryption is that recryption service can make all the encrypted material available to a new recipient that is added to a recryption group including messages sent before she was added. To add a Carol to the recryption group as a receiver, Alice just repeats the same process she performed for Bob. Removing recipients from a recryption group requires the administrator to tell the recryption service to no longer recrypt messages to the removed user's recryption key. This requires the recryption service to be trusted not to forward messages to the deleted user. To restore the untrusted status of the recryption service it is necessary for the administrator to create a new encryption key and a full set of recryption keys for the continuing users. One major limitation in the trust model of the recryption scheme described is that while it is not possible for either the recryption service or individual recipients to decrypt arbitrary messages the recryption service and a recipient may do so if they collude. This particular limitation in the trust model is an inescapable consequence of the fact that the function of the recryption service is to enable a recipient to decrypt a message and cannot be avoided without introducing additional parties. This limitation is not considered to be a serious limitation for the intended application. 3.2. Mailing Lists One of the earliest uses proposed for recryption is to support end- to-end security for a confidential mailing list in which the membership of the list is not disclosed to its members. In this application, the mail server is a recryption service and trusted to maintain the confidentiality of the mailing list membership but not the messages themselves. This offers many advantages over existing approaches: Messages are encrypted end-to-end It is not necessary for senders to know the membership of the list. New members added to the list can read messages sent before they joined. Hallam-Baker Expires February 23, 2017 [Page 10] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 To apply recryption to a mailing list server, a recryption keyset is created for each mailing list managed by the server and the administrator responsible for maintaining the membership of the list is also the administrator of the corresponding recryption key set. 3.3. Chat rooms and other streaming data. The application of recryption to a chat room application is similar to the mailing list application except that the administrator may be either an offline party as before or a participant in the conversation. In the latter case, the protocol should permit the administrator to pass their role to another participant should they need to leave. One major constraint on the use of recryption to support streamed audio or video is that since the messaging service cannot decrypt the data stream, it can hardly be expected to perform transcoding services such as producing lower resolution versions of a video stream to support participants with low bandwidth connections. Either all the participants must receive the exact same data feed or transcoding services must be provided by a trusted party granted access by the administrator. 3.4. Confidential Document Control Confidential Document Control (CDC) uses cryptography to enforce access control. Unlike Digital Rights Management and related technologies, CDC only provides a means to permit or deny access to confidential data while it is under protection. A CDC infrastructure does not attempt to control the use made of that data by an authorized recipient, in particular, a CDC infrastructure does not necessarily prevent redistribution of data by a party permitted to read it. The application of recryption to CDC maps naturally to the use of 'security labels' to control access to confidential documents in government and military applications. Each security label (e.g. secret#example.com) has an associated recryption key set. The administrator of the recryption key set is responsible for managing the parties authorized to read documents controlled under that label. Recryption may be used to support the use of multiple labels. Combining appropriate cryptographic operations permits a document author to require recipients to be granted access for all the labels specified or for any of the labels specified. For example, the designation (Accounting#example.com + Executive#example.com) might indicate that a recipient must be a member of the Accounting and Executive teams while the designation (Accounting#example.com | Hallam-Baker Expires February 23, 2017 [Page 11] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 Executive#example.com) would enable members of either team to read the material. Since users must request a recryption key from the recryption service for each document accessed, the recryption service is a Policy Control Point and is thus potentially a point at which additional accountability and/or access controls may be introduced. An enterprise recryption service might maintain a log of all access requests from users and restrict access to users whose requests exceed some form of quota. Attempts to access particularly sensitive documents might raise flags requiring review by a supervisor. 3.5. Multiple Devices When the S/MIME and OpenPGP email encryption schemes were developed in the 1990s the machines of the day, if movable at all were 'portable' rather than 'mobile'. Contemporary users demand access to their communications applications from a wide variety of devices including desktops, laptops, tablets, phones and even watches. The need for a single user to access their email on multiple devices is now the norm rather than the exception. Use of multiple devices and in particular mobile devices introduces obvious security concerns. A device may be lost or stolen; a machine may be sold without destroying data stored on it. Such circumstances very frequently result in disclosure of private keys to an attacker. Maintaining separate private keys on each device allows the consequences of such loss to be mitigated and further compromise prevented. To apply recryption to this use case, the email recipient establishes a personal recryption keyset on a machine that they consider at least risk of compromise. A separate recryption key entry is then created for each device and the recryption keyset uploaded to a suitable recryption server host (e.g. the presence service of a chat application, inbound mail server, etc.) One difficulty that arises in this approach is that while a non- transitive recryption mechanism can be applied in either a sender side context such as a mailing list or a receiver side context such as supporting multiple devices, enabling the use of both at the same time requires additional effort. 4. Mesh/Recrypt Mesh/Recrypt is a messaging infrastructure built on the Mathematical Mesh infrastructure that supports end-to-end encryption with: Hallam-Baker Expires February 23, 2017 [Page 12] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 o * Confidential Document Control * Asynchronous messaging (e.g. mail, mailing lists) * Synchronous messaging (e.g. chat, voice, video) Mesh/Recrypt builds on the same suite of existing Internet standards and specifications as the Mathematical Mesh. These include: o * All messages and data structures are encoded using either JSON encoding or the extended JSON-C encoding that offers efficient binary encoding and compression of field tags and strings. * All services are implemented as Web Services using HTTP transport and TLS for transport layer security. * Message layer security is provided using JOSE signature and Encryption. * Uniform Data Fingerprints are used to identify public keys * Use of DNS SRV records for Web Service discovery * Use of the .well-known convention to specify the Web Service endpoint. One significant limitation in the current implementation is that it uses traditional Diffie Hellman key exchange in a finite field rather than the newly defined CFRG elliptic curve algorithms. This is due to the version of the development environment having not caught up with the development of the new standards yet. For clarity, the use of the command line tool 'recrypt' is shown. For most production use, a GUI interface or integration of the recryption functions into the document editing and/or viewing tools would be preferred. 4.1. Scenario Since Confidential Document Control is the application that is not currently supported by existing open standards, we present this as the example use case. The extension of the approach to other messaging modalities will be considered separately. Hallam-Baker Expires February 23, 2017 [Page 13] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 In the following examples, the named parties have the following roles: Alice The owner and administrator of the recryption group 'privatealice@example.com'. She decides who is permitted to read documents that have been encrypted to this group and generates the necessary recryption keys. Bob The person Alice grants read access to her controlled documents. Service The service that enforces control of controlled documents. Note that the Service is only one part of the CDC infrastructure. Alice sets policy for who is permitted access to the controlled documents using the recrypt tool. The service is responsible for enforcement of that policy. 4.2. Parties create a Mesh personal profile Alice creates a Mesh personal profile with a Mesh/Recrypt profile. This can be done using a Mesh profile management tool or the recrypt tool. The recrypt tool generates a Mesh/Recrypt profile by default: recrypt /personal alice@example.com Bob and Carol do likewise but using a different Mesh portal. recrypt /personal bob@example.net recrypt /personal carol@example.net At this point Alice, Bob and Carol have established a persistent personal PKI. Since it is the only profile each has established for the account they are using on the computer, it is automatically registered as the default profile for that account and does not need to be specified in future commands. To simplify future examples, we assume that Alice and Bob have established each other's profiles as trustworthy via some out of band process. This might be through a direct trust model (i.e. exchange of profile fingerprints), a brokered trust mode (e.g. a certificate issued by a CA) or some other mechanism to be determined. Hallam-Baker Expires February 23, 2017 [Page 14] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 To use the protocol, the recyption service also requires a Mesh/ Recrypt profile containing a public key to use for encryption. For simplicity we assume that this is a WebPKI certificate using an appropriate validation mechanism (e.g. Extended Validation). 4.3. Alice creates a recryption group To create a recryption group, Alice just needs to specify the name for the group. Since this is a group for Alice's personal use, and the recryption service will be managed by her Mesh portal, she chooses the name privatealice@example.com. [The extent to which this convention is useful and/or requires enforcement steps to be taken by portals is not currently understood. It seems like a good idea but might not be.] recrypt /newgroup privatealice@example.com As with any other Mesh profile, the recryption group has both a friendly name and a UDF fingerprint. The recryption group contains a master signature key and an encryption key and is signed under the signature key: Recrypt profile... The newly created recryption profile is published to both the recryption service and the Mesh Portal. Note that even though the Mesh Portal and Recryption Service are both provided by the same domain (example.com), these are distinct Web Services and may be hosted on separate machines. Since the use of a recryption group is a stored data encryption application and Alice has opted to create a personal escrow key, the recrypt client also 4.4. Alice encrypts a document Alice creates a text document containing the text 'this is a test' and saves it under the filename text.txt. To encrypt the document to the recryption group, Alice specifies the file she wishes to encrypt and the name of the group: recrypt /encrypt privatealice@example.com test.txt Hallam-Baker Expires February 23, 2017 [Page 15] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 The recryption client fetches the current recryption group profile from the Mesh Portal and verifies that it meets the relevant trust criteria. Since privatealice@example.com is a sub-account of alice@example.com which Alice trusts because it is her own account. It suffices for the client to verify that Alice's current Mesh profile has an entry for the recryption group and has a valid signature. Having acquired the recryption group profile, the client extracts the group encryption key and uses it to create a JOSE encrypted message: TBS The encrypted data is a wrapper that specifies the content metadata. TBS The encrypted document is saved as test.txt.jcd (Jose Controlled Document) The message format has been designed to permit authenticated and encrypted messages to be generated and recieved as message streams without the need to buffer content. A protected message consists of a list containing the following items in order: o * Header specifying the information necessary to decrypt the message and the authentication algorithm. * The encrypted data. * Trailer specifying the authentication value. One disadvantage of using JSON encoding in an encryption scheme is that the need to encode binary data as Base63 encoded strings incurs a 33% inflation penalty on each pass. For this reason, Mesh/Recrypt applications are required to accept (but not generate) the JSON-B and JSON-C encodings which permit binary data to be encoded directly. 4.5. Alice adds Bob and Carol to the recryption group Alice adds Bob and Carol to the recryption tool by specifying their profile identifiers: recrypt add privatealice@example.com bob@example.net recrypt add privatealice@example.com carol@example.net Hallam-Baker Expires February 23, 2017 [Page 16] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 To add each user the client: o * Acquires and validates the user's Mesh profile * Obtains the private key for the recryption group (stored on the machine). * Creates a recryption entry as described earlier. * Encrypts recryption entry under the encryption key of the recryption service. * Publishes the encrypted recryption entry to the service using a secure channel (HTTPS to the Server WebPKI certificate). The encrypted recryption entry is: TBS The encrypted content within the recryption entry is: TBS 4.6. Bob decrypts a document Alice sends the encrypted controlled document to Bob by whichever means is most convenient. Alice might send the document to Bob by email, hand him a USB thumdrive or just save the document to an enterprise file server that Bob has access to. To read the document, Bob must decrypt it. Ideally the encryption and decryption of documents would be handled transparently by the application and/or platform. Instead Bob uses the recrypt tool: recrypt /decrypt test.txt.jcd To decrypt the document, the client: o * Reads the document header to determine that it is a recrypted document * Obtain a recryption grant from the recryption service indicated. This is encrypted under Bob's encryption key. Hallam-Baker Expires February 23, 2017 [Page 17] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 * Decrypt the recryption grant and the user portion of the recryption private key * Combine the user and service data * Decrypt the message The recryption service may require Bob to authenticate before the recryption grant is provided. This prevents denial of service attacks on the service and allows the service to enforce quotas and/ or accountability controls. 4.7. Bob uses multiple devices Recryption may be used to support multiple devices in more than one way. The approach that is most appropriate depends on the precise use scenario. The simplest method of supporting multiple devices is for Alice to create multiple recryption entries for Bob, one for each of his authorized devices. Alice might prefer this approach despite the additional work for her because it allows her to decide which of Bob's devices are authorized to read the documents she controls. The chief limitation of this approach is that Bob must obtain Alice's approval to add or remove devices. In a more sophisticated approach, Bob administers his own recryption group and creates recryption keys for each device that is not to be an administrator device for the group. These are called standard devices. To read Alice's document on a standard device, the device must first obtain the recryption key from Alice's recryption service as before, then contact Bob's recryption service to decrypt the recryption grant. [It is not clear at this stage how much data this leaks to the client and to what extent Bob is trusting the recryption service to enforce policy. Each ordinary device gains access to Bob's decryption key for the group. Instead of using recryption to control access to the document itself, this approach uses recryption to control access to the recryption grant used to unlock the document.] [For the most sensitive documents, Bob can reduce the degree of trust in the recryption service by obtaining his recryption private user key for a group and creating a recryption keyset for that device. The principal disadvantage of this approach is that this requires Alice and Bob to perform an administration operation when the group Hallam-Baker Expires February 23, 2017 [Page 18] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 is created and each time the keys are changed. Another disadvantage is that if Bob has ten devices and is a member of a hundred recryption groups, he will need to administer a thousand individual recryption entries.] 4.8. Alice revokes Carol's group membership At minimum, revoking Carol read access to the group requires the client to inform the recryption service that the entry for Carol should be deleted. Relying on the recryption service to enforce the policy change requires the service to be trusted which may or may not be acceptable. If the confidential data being controlled is particularly sensitive, Alice can block access to any new material encrypted under the group with a rollover of the group key and set of recryption keys. A client might perform such a key rollover by default if the number of entries in the group is small. 4.9. Bob loses a device The loss of a device requires Bob to perform the same tasks as Alice did to remove Carol from the recryption group. 4.10. Bob visits a hostile environment If Bob knows that he is going to be visiting an environment where his device may be searched by agents who may coerce him to reveal any decryption keys, he may avoid disclosure of confidential material by removing the device from the recryption group and deleting all the unencrypted confidential from it. Bob access to the confidential material may be quickly restored through the introduction of a trusted third party. Before leaving, Bob creates a recryption entry, and encrypts it under an encryption key unique to the device he is to use. This information is sent to the trusted third party via a secure channel. To regain access to the material, Bob must convince the trusted third party that he is safe and not in a situation he is subject to coertion. 5. Recrypt Service Reference SRV Prefix: _meshrecrypt._tcp Hallam-Baker Expires February 23, 2017 [Page 19] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 HTTP Well Known Service Prefix: /.well-known/meshrecrypt TBS 5.1. Request Messages A Mesh/Recrypt request consists of a payload object that inherits from the RecryptRequest class. When using the HTTP binding, the request MUST specify the portal DNS address in the HTTP Host field. 5.1.1. Message: RecryptRequest Base class for all request messages. Portal: String (Optional) Name of the Mesh/Recrypt Service to which the request is directed. 5.2. Response Messages A Mesh/Recrypt response consists of a payload object that inherits from the RecryptResponse class. When using the HTTP binding, the response SHOULD report the Status response code in the HTTP response message. However the response code returned in the payload object MUST always be considered authoritative. 5.2.1. Message: RecryptResponse Base class for all response messages. Contains only the status code and status description fields. A service MAY return either the response message specified for that transaction or any parent of that message. Thus the RecryptResponse message MAY be returned in response to any request. Status: Integer (Optional) Status return code. The SMTP/HTTP scheme of 2xx = Success, 3xx = incomplete, 4xx = failure is followed. Hallam-Baker Expires February 23, 2017 [Page 20] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 StatusDescription: String (Optional) Text description of the status return code for debugging and log file use. 5.2.2. Successful Response Codes The following response codes are returned when a transaction has completed successfully. [201] SuccessOK Operation completed successfully [201] SuccessCreated Operation completed successfully, new data item created [202] SuccessUpdated Operation completed successfully, data item was updated 5.2.3. Warning Response Codes The following response codes are returned when a transaction did not complete because the target service has been redirected. In the case that a redirect code is returned, the StatusDescription field contains the URI of the new service. Note however that the redirect location indicated in a status response might be incorrect or even malicious and cannot be considered trustworthy without appropriate authentication. [303] RedirectPermanent Service has been permanently moved [307] RedirectTemporary Hallam-Baker Expires February 23, 2017 [Page 21] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 Service has been temporarily moved 5.2.4. Error Response Codes A response code in the range 400-499 is returned when the service was able to process the transaction but the transaction resulted in an error. [401] ClientUnauthorized Client is not authorized to perform specified request [404] NotFound The requested object could not be found. [409] AlreadyExists The requested object already exists. 5.2.5. Failure Response Codes A response code in the range 500-599 is returned when the service was unable to process the transaction but the transaction due to an internal failure. [500] ServerInternal An internal error occurred at the server [503] ServerOverload The server cannot handle the request as it is overloaded Hallam-Baker Expires February 23, 2017 [Page 22] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 5.3. Imported Objects The Mesh/Remesh Service protocol makes use of JSON objects defined in the JOSE Signatgure and Encryption specifications. 5.4. Common Structures The following common structures are used in the protocol messages: 5.4.1. Structure: Version Describes a protocol version. Major: Integer (Optional) Major version number of the service protocol. A higher Minor: Integer (Optional) Minor version number of the service protocol. Encodings: Encoding [0..Many] Enumerates alternative encodings (e.g. ASN.1, XML, JSON-B) supported by the service. If no encodings are specified, the JSON encoding is assumed. URI: String [0..Many] The preferred URI for this service. This MAY be used to effect a redirect in the case that a service moves. 5.4.2. Structure: Encoding Describes a message content encoding. ID: String [0..Many] Hallam-Baker Expires February 23, 2017 [Page 23] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 The IANA encoding name Dictionary: String [0..Many] For encodings that employ a named dictionary for tag or data compression, the name of the dictionary as defined by that encoding scheme. 5.4.3. Structure: Resource Identifier: String (Optional) 5.4.4. Structure: Static o * Inherits: Resource [None] 5.4.5. Structure: Dynamic o * Inherits: Resource [None] 5.4.6. Structure: ResourceSet o * Inherits: Resource [None] 5.4.7. Structure: User o * Inherits: Resource Account: String (Optional) Hallam-Baker Expires February 23, 2017 [Page 24] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 5.4.8. Structure: Label o * Inherits: Resource [None] 5.4.9. Structure: KeySet o * Inherits: Resource Account: String (Optional) Administrators: User [0..Many] Readers: User [0..Many] 5.5. Transaction: Hello Request: HelloRequest Response:HelloResponse Report service and version information. The Hello transaction provides a means of determining which protocol versions, message encodings and transport protocols are supported by the service. 5.5.1. Message: HelloRequest o * Inherits: RecryptRequest [None] 5.5.2. Message: HelloResponse o * Inherits: RecryptResponse Always reports success. Describes the configuration of the Mesh portal service. Hallam-Baker Expires February 23, 2017 [Page 25] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 Version: Version (Optional) Enumerates the protocol versions supported Alternates: Version [0..Many] Enumerates alternate protocol version(s) supported 5.6. Transaction: Set Request: SetRequest Response:SetResponse 5.6.1. Message: SetRequest o * Inherits: RecryptRequest [None] 5.6.2. Message: SetResponse o * Inherits: RecryptResponse [None] 5.7. Transaction: Get Request: GetRequest Response:GetResponse 5.7.1. Message: GetRequest o * Inherits: RecryptRequest [None] Hallam-Baker Expires February 23, 2017 [Page 26] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 5.7.2. Message: GetResponse o * Inherits: RecryptResponse [None] 5.8. Transaction: Delete Request: DeleteRequest Response:DeleteResponse 5.8.1. Message: DeleteRequest o * Inherits: RecryptRequest [None] 5.8.2. Message: DeleteResponse o * Inherits: RecryptResponse [None] 5.9. Transaction: Select Request: SearchRequest Response:SearchResponse 5.9.1. Message: SearchRequest o * Inherits: RecryptRequest [None] Hallam-Baker Expires February 23, 2017 [Page 27] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 5.9.2. Message: SearchResponse o * Inherits: RecryptResponse [None] 5.10. Transaction: Join Request: JoinRequest Response:JoinResponse 5.10.1. Message: JoinRequest o * Inherits: RecryptRequest [None] 5.10.2. Message: JoinResponse o * Inherits: RecryptResponse [None] 5.11. Transaction: Leave Request: LeaveRequest Response:LeaveResponse 5.11.1. Message: LeaveRequest o * Inherits: RecryptRequest [None] Hallam-Baker Expires February 23, 2017 [Page 28] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 5.11.2. Message: LeaveResponse o * Inherits: RecryptResponse [None] 6. Further Work 6.1. Payment Integration 6.2. Contact Management 6.3. SMTP, IMAP and POP3 Integration 6.4. S/MIME Extensions 6.5. OpenPGP Extensions 7. Acknowledgements 8. Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC 6982. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to RFC 6982, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". Hallam-Baker Expires February 23, 2017 [Page 29] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 8.1. Reference Implementation Organization: Comodo Group Inc. Implementer: Phillip Hallam-Baker Maturity: Experimental Prototype This implementation was used to produce the reference section and all the examples in this document. Since the conversion of specification to code is automatic, there is a high degree of assurance that the reference implementation is consistent with this document. 8.1.1. Coverage: The draft-xx branch describes the code used to create version xx of this document. The main current limitations are that the code only supports RSA key pairs and for ease of development the server does not persist keys across sessions. Nor does the implementation currently support the HTTP payload authentication and encryption layer or make use of TLS. These could be easily fixed. The client and server are implemented as libraries that may be called from a multi-protocol server. A standalone server will be provided in a future release. Only the JSON encoding is currently implemented. The JSON-B, JSON-C, ASN.1 and TLS Schema implementations are all supported by the code generation tool but not currently implemented as the build tool bindings for those encodings have not yet been finalized or documented. The key restrictions for TLS key exchange have not yet been implemented. The code has only been tested on Windows 10 but passed compatibility testing for both Mono and dotNetCore 10 run times which should in theory permit use on Linux and OSX platforms. 8.1.2. Licensing The code is released under an MIT License Source code is available from GitHub at https://github.com/hallambaker/LURK-PHB Hallam-Baker Expires February 23, 2017 [Page 30] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 8.1.3. Implementation Experience The implementation and specification documentation were developed in Visual Studio using the PHB Build Tools suite. 8.1.4. Contact Info Contact Phillip Hallam-Baker phill@hallambaker.com 9. Security Considerations [This is just a sketch for the present.] 10. IANA Considerations [TBS list out all the code points that require an IANA registration] 11. References 11.1. Normative References [draft-hallambaker-json-web-service-02] "[Reference Not Found!]". [draft-hallambaker-jsonbcd-05] "[Reference Not Found!]". [draft-hallambaker-mesh-architecture-01] "[Reference Not Found!]". [draft-hallambaker-mesh-reference-02] "[Reference Not Found!]". [draft-hallambaker-udf-03] "[Reference Not Found!]". [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008. [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014. [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015. Hallam-Baker Expires February 23, 2017 [Page 31] Internet-Draft Mesh/Recrypt A New Approach to Messaging August 2016 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015. [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015. [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016. 11.2. Informative References [Blaze] "[Reference Not Found!]". Author's Address Phillip Hallam-Baker Comodo Group Inc. Email: philliph@comodo.com Hallam-Baker Expires February 23, 2017 [Page 32]