Vessel Container Format

2.1.1. Pseudo-Code Conventions

Character and String Literals:

We quote single characters in single quotes (') and character strings in double quotes ("). Characters and strings may be encoded in different encodings; this is noted in the surrounding text. Typically, we use ASCII for text used within the specification itself, and UTF-8 [RFC3629] for application provided text.¶

Concatenation:

We use the pipe character (|) to denote concatenation.¶

Function Calls:

Function calls are represented as the majority of programming languages implement them, with a function name, and parameters enclosed by an opening and closing bracket pair (). Parameters are delimited by commas (,), e.g. foo(bar, baz).¶

Truncation:

When we discuss truncating octet sequences in this document, we assume a pseudo-code function truncate(input, size) exists that returns the first size octets from the input octet sequence.¶

Size:

Pseudo-code furthermore assumes the existence of a length() function that returns the length of a given field, or octet sequence, etc.¶

Names:

Similar to the size function, a name() function is assumed that returns canonical names for algorithm choices.¶

3.2.1. Version Tag Algorithm

The algorithm for generating the version tag is relatively simple: concatenate all the choices of algorithms by their canonical identifier, separated by a semi-colon ; (U+003B) and apply the version tag hash function. Then concatenate the string "Vessel" with the output of the prior function invocation, and apply the version tag hash function again. Of the result, use as many octets from the start as the version tag requires.¶

The canonical identifiers are listed in Section 3.8. They are all ASCII text, such that no other character set considerations are necessary.¶

algorithms = name(version_tag_hash) |
  ';' | name(extent_identifier_hash) |
  ';' | name(author_identifier_hash) |
  ';' | name(nonce_hash) |
  ';' | name(signature_hash) |
  ';' | name(asymmetric_signature) |
  ';' | name(message_authentication) |
  ';' | name(symmetric_encryption) |
  ';' | name(signature_algorithm) |
  ';' | private_header_flag

pre_hash = version_tag_hash(algorithms)

hash = version_tag_hash("Vessel" | pre_hash)

version_tag = truncate(hash, length(version_tag))

Given the relatively low number of possible inputs to this scheme, even a truncated hash has a high likelihood of remaining collision free. At the same time, the algorithm is simple enough to be implemented on many platforms. It also is strictly deterministic. The scheme is also sufficiently future proof. Addition of more algorithms is well supported by simply appending them to the concatenation list.¶

Note that implementations MUST treat all strings and individual characters in this algorithm as ASCII encoded.¶

• The signature_algorithm is a reference to one of the other algorithms only. Its possible values have special meaning, as described in Section 3.8.6.¶
• Conversely, the private_header_flag may only be one of two special words, ph=0 or ph=1 respectively, where ph stands for "private header", and a value of zero (0) indicates that private headers are not used, while a value of one (1) shows that they are.¶

algorithms = "sha3-512" | # name(version_tag_hash)
  ';' "sha3-512" |        # name(extent_identifier_hash)
  ';' "none" |            # name(author_identifier_hash)
  ';' "sha3-512" |        # name(nonce_hash)
  ';' "eddsa" |           # name(signature_hash)
  ';' "ed25519" |         # name(asymmetric_signature)
  ';' "kmac128" |         # name(message_authentication)
  ';' "chacha20" |        # name(symmetric_encryption)
  ';' "aead" |            # name(signature_algorithm)
  ';' "ph=1"              # private_header_flag
# Results in:
# "sha3-512;sha3-512;none;sha3-512;eddsa;ed25519;kmac128;chacha20;aead;ph=1"

pre_hash = version_tag_hash(algorithms)

hash = version_tag_hash("Vessel" | pre_hash)

version_tag = truncate(hash, length(version_tag))
# Results in (hexadecimal): f8059ab6

3.3.1. Envelope

The envelope layout is as follows. Note that in the diagram below we list specific bit sizes for fields; these are not open to interpretation and MUST be implemented exactly as specified.¶

1. A "magic" three octet sequence consisting of ASCII values 88 ('X'), 69 ('E') and 86 ('V'), together forming the string "XEV". Read backwards, "XEV" is "VEX", which may be considered shorthand for "Vessel EXtent".¶
2. A single octet containing the envelope version (see Section 3.2).¶
3. A four octet sequence with the version tag (see Section 3.2).¶

A fixed-sized envelope containing all relevant versioning information is sufficient for graceful adaptation to future specification changes. Furthermore, the envelope is long enough to serve as a synchronization boundary for detecting extents within a octet stream.¶

Note again that the envelope version relates only to the layout of this envelope. The first four octets MUST remain fixed in size and meaning (although it is possible to change the "XEV" string into a different one of the same size), otherwise the envelope version cannot be reliably read.¶

The envelope version exists primarily to permit graceful handling of future changes to the version tag, or addition of envelope metadata.¶

3.3.2. Header

Following the envelope information, the extent header provides metadata about the extent itself. The exact layout of the header depends on the version tag.¶

The primary reason for this is that the choice of different cryptographic algorithms implies different field lengths e.g. for identifiers specified in the header. Implementations MUST adjust to this, for all combinations of such algorithms they support. However, implementations MUST NOT deviate from the sequence of fields below.¶

Note that for this reason, the display sizes of 48 bits for extent and author identifiers given in this document should be considered examples only.¶

1. The extent size. This is a 16 bit unsigned integer value in big endian encoding. It specifies the size of the extent from the beginning of the envelope to the end of the footer. The value MUST be interpreted as a multiplier of a nominal block size of 4096 octets, yielding possible extent sizes from 4096 octets to 256 MiB.¶
2. The current extent identifier follows; see Section 3.5 for details.¶
3. An authoring counter follows. This is a 24 bit unsigned integer value in big endian encoding. Authors must increment this counter for every update to any extent they make; see Section 3.6.2 for details.¶
4. The next field specifies the previous extent's identifier. If the extent is the origin extent, its value MUST be a sequence of NULL octets.¶
5. Following this, is the author identifier. The identifier SHOULD be mappable to an authoring key pair, to permit authentication of the extent payload. It MUST be mappable to an authoring key pair if an asymmetric signature algorithm is chosen to validate the extent payload.¶

3.3.3. Payload

octets following the header, up to the beginning of the footer, are extent payload.¶

The payload contains the application data. Though the extent size is fixed, applications may provide arbitrary length data for encapsulation. For this reason, application data is encapsulated in sections within the payload; see Section 3.4 for details.¶

Different sections may have different length, but sections either include their own length specifier, or the version tag information provides an indication of the section length. Thus the payload consists of zero or more sections, each of which has a determinate length.¶

If the total length of all sections is less than the size of the payload area (the size of the extent minus the size of envelope, header and footer), then the remainder of the payload area MUST be filled with padding octets.¶

payload_size = extent_size
    - envelope_size
    - header_size
    - footer_size

padding_size = payload_size - cumulative_section_sizes

padding_value = padding_size modulo 256

3.3.4. Footer

The footer contains only a signature, which verifies the entire extent. The size of the signature is dependent on the signature algorithm scheme which is defined by the version tag, and provided as 64 bits here for display purposes.¶

1. The signature field. The range of data covered by the signature starts at the beginning of the envelope, and ends at the end of the payload.¶

Signatures are calculated after potential encryption of the payload.¶

3.3.5. Full Extent Layout

The full layout of an Extent is as follows; as with the identifier sizes, the payload size below is limited to 200 bits for display purposes only.¶

3.4.1. Fixed-Sized Sections

Some section types imply a fixed section size. For these sections, it is not necessary to carry additional size information, and the layout is as follows.¶

3.4.2. Variable-Sized Sections

Other sections are variable sized; this is almost certainly the case for opaque application data.¶

Sections can never be larger than the extent within which they are encapsulated. However, sections need not be a multiple of 4096 octets in size as extents are.¶

It would be possible to encode the section size in 28 bits, but such an encoding is hard. Instead, we use a simple variable sized encoding scheme as described in Section 3.4.3.1.¶

To maintain compatibility with the fixed-size section header, the section size follows the topic.¶

3.4.3. Section Fields

1. The section type is a 16 bit unsigned integer in big endian encoding. Types below 1024 are reserved; applications must specify the types they intend to use. In order for applications to determine compatibility with any such scheme, a special content type section is used (Section 3.4.5.4).¶
2. The topic is also a 16 bit unsigned integer in big endian encoding. Topics below 1024 are reserved. The same content type section as above is used to determine application compatibility.¶
3. If present, the section size is either 16 or 32 bits in length. The value of the first 16 bits determines if more bits follow (Section 3.4.3.1).¶
4. The remainder of the section is section payload.¶

Note that the section size determines the size of the entirety of the section, not the section payload size. This is largely to stay more consistent with the dealing with fixed sized sections; in either case, reading the section header gives you all the information to jump from the start of the section to its end.¶

3.4.4. Topics

As described in Section 3.4.3, section headers carry a 16 bit topic value. Topic values below 1024 are reserved for use in this specification or later revisions or extensions; the remainder are application choices.¶

3.4.5. Predefined Sections

The following describes sections defined in this specification.¶

Sections may be valid only in combination with a specific topic. If that is the case, such valid topics are listed here or in the respective section descriptions. If no such restriction is listed, the section may appear in any topic.¶

Section values below 1024 are reserved for use in this specification or later revisions or extensions; the remainder are application choices.¶

If a section appears in an invalid topic, implementations MUST ignore it. They SHOULD emit warnings about malformed extents as far as they have provisions for doing so, and MAY reject the entire extent.¶

Note in particular that there is no generic "data" section defined here. This is done purposefully, such that applications MUST define at least one section type.¶

3.5.1. Deterministic Ordering

Simply generating extent identifiers as outlined above will effectively yield a directed acyclic graph (DAG) of extents; more precisely, the result is a simple tree. In order to fulfil the last requirement above, we need a means by which authors deterministically choose the previous extent upon which they build.¶

As extents may not be always synchronized across all nodes, the approach provided here may still created branches. As extents become synchronized, however, all authors will converge on the same previous extent, thereby collapsing all branches again.¶

Eventual synchronization can mean that the origin extent is not known to a node at any given time. This means an incomplete resource may be known as a collection of sub-trees. The algorithm here nevertheless provides a deterministic means for finding the ideal extent identifier to use as the basis for a newly created one.¶

For illustration purposes, consider the following example:¶

First, we order extent identifiers by simple bitwise comparison. In the above example, this means that B2 follows B1, and B3 follows both, etc.¶

For the full algorithm, it is necessary to calculate the weight of each path from the root node at extent A, to all other nodes. The weight of each edge from a source to a target node is defined as one divided by the number of target nodes that lead from the source node. Alternatively, this is the number of siblings, including itself, that exist for the target node.¶

In this example, paths 7 and 8 have the highest weights. To tie break between paths of equal weight, the path wins whose leaf node comes last in bitwise ordering. In this example, F2 comes after F1, so path number 8 wins.¶

Authors MUST select the leaf node of the winning path as the previous extent for creating a new extent.¶

Over time, this algorithm will converge on the longest and least ambiguous path. Nodes with fewer siblings have higher edge weights, and more nodes in the path will create a higher cumulative weight.¶

The algorithm will even lead to convergence after a major network split. Assume network A knows only a sub-tree TA, and network B knows only a sub-tree TB. Assume further that the winning paths in both sub-trees TA and TB have the same cumulative weight W. The two sub-trees will nonetheless have different leaf node extent identifiers, leading to a deterministic winner when both sub-trees are finally synchronized.¶

Note that the deterministic ordering scheme presented here is comparable to [TREEDOC]. However, instead of generating identifiers in some semantic order, this specification is only concerned with deterministic ordering. The disambiguator here is the inclusion of the authoring key, which is sufficient for the purposes of an abstract container.¶

3.6.1. Author Identifiers

Author identifiers are derived from key pairs . Generally speaking, a public key serves as a sufficiently unique identifier in that a cryptographic challenge can be issued that only the party in possession of the corresponding private key can successfully respond to. Such a challenge protocol is outside of this document's scope.¶

Key fingerprints are often used as shorter, unique stand-ins for public keys. Unfortunately, each cryptosystem tends to define its own method for generating such fingerprints. The general approach, however, is to use a cryptographic hash function over a deterministic encoding of the key parameters.¶

For generating author identifiers, author public keys MUST be encoded using the Distinguished Encoding Rules (DER) of [X.690]. The author identifier hash function is an implementation choice. The resulting hash may be further truncated.¶

encoded = DER(author_public_key)

hash = author_identifier_hash(encoded)

author_identifier = truncate(hash, length(author_identifier))

3.6.2. Authoring Counter

Extents are mutable; their content can change over time, while their identifier stays stable. This has benefits in addressing e.g. the right to be forgotten, but a downside is that means other than a content hash have to be found in order to signal that one version of an extent differs from another.¶

To provide this, we introduce the authoring counter . It is a counter value scoped to the tuple of author identifier and resource - that is, multiple authors may use the same value, and the same author may use the same value across multiple resources.¶

Whenever authors write to an extent, they also need to update the signature. Prior to doing so, they MUST increment the authoring counter they maintain for the resource, and write it to the header (i.e. the signature must extent also to this new counter value).¶

Doing so lets protocol implementations and receiving nodes quickly ascertain if an extent is a newer version (larger authoring counter than locally stored) or older version, and reject and/or delete older content. In order to maintain the right to be forgotten, implementations MUST delete extents thus outdated.¶

Nodes SHOULD implement means by which to detect other nodes that do not conform to this, as possible. Nodes SHOULD keep a record of versions sent to nodes, and if those nodes return older versions, blocklist them. Reasonable precautions SHOULD be taken to avoid feeding content to malicious or malfunctioning nodes, but such precautions are difficult to enforce remotely, and somewhat outside the scope of this specification.¶

The stable identifier and authoring counter method has benefits over the more common content hashing:¶

1. It is possible to detect outdated and updated versions, rather than merely detecting difference.¶
2. Approaches to creating resource identifiers from the sum of the extent signatures such as using merkle signature schemes (e.g. [RFC8391]) require the generation and propagation of a new resource identifier if a single component changes; this is less often the case if a similar tree scheme using stable extent identifiers was used.¶
3. Most importantly, the scheme does not break the deterministic ordering scheme described in Section 3.5.1.¶

Authoring counters do not have to be incremented strictly by one. The only requirement is that new counters are larger than previously written ones. Wrap-around will occur eventually, which is why implementations SHOULD use a reasonably large counter, and MUST use, at minimum, an unsigned integer of 24 bits or larger.¶

3.7.1. Encrypt-then-Sign

Authenticated encryption schemes that first encrypt the plain text, and then sign the resulting cipher text do not provide an easy means for determining whether the decryption was successful.¶

When using such schemes, implementations MUST provide one of the CRC32 (Section 3.4.5.1), MAC (Section 3.4.5.2) or signature sections (Section 3.4.5.3). The presence of either already indicates that decryption was successful, and the section contents can extend this verification to the remaining payload.¶

Encrypt-then-MAC is recommended by [ISO-19772]. It is also conceptually the way AEAD schemes function.¶

3.7.2. Sign-then-Encrypt

When plain text is first signed, then encrypted, it is usually the case that the signature is concatenated to the plain text before encryption. In this manner, presence of the signature after decryption also indicates that decryption succeeded.¶

It is possible to emulate this by providing MAC (Section 3.4.5.2) or signature section (Section 3.4.5.3), and then using an otherwise unauthenticated stream cipher for encryption. The length of the signature in the footer would then be zero octets.¶

This mode is not supported by Vessel, and implementations MUST NOT use it.¶

3.7.3. Sign-then-Encrypt-then-Sign

In [SIGN-ENCRYPT], the author contests that neither sign-then-encrypt nor encrypt-then-sign provides sufficient guarantees for asymmetric encryption schemes. There is no guarantee in either case that the signing party and the encrypting party are identical, which can lead to some subtle forgery attacks.¶

It is possible to create that link by using a sign-then-encrypt-then-sign scheme in which the inner and outer signatures are verifiably made by the same party, with the implication that they at minimum agreed to the encryption.¶

As the symmetric ciphers permitted by this specification are already AEAD schemes of the sign-then-encrypt style, and based on a kind of MAC construct, a sign-then-encrypt-then-sign construction is reached if:¶

1. Encrypt-then-sign is used as in Section 3.7.1.¶
2. The checksumming section chosen is a MAC section (Section 3.4.5.2).¶
3. The key and nonce are identical for the MAC as for the outer AEAD scheme.¶

Implementations using confidentiality SHOULD use a MAC section in this manner. If the MAC section is chosen, implementations MUST use the same key and nonce as in the AEAD construction. See Section 3.8.4 for details.¶

3.7.4. Encrypted Extent Parts

Some extent fields must remain in plain text in order to identify and otherwise work with the extent, even if its contents remain encrypted.¶

1. The envelope is always in plain text. It is necessary for understanding anything at all about the extent layout. It also does not leak any sensitive meta information.¶
2. If encryption occurs, the payload is always encrypted in its entirety, including any padding.¶
3. The signature is always in plain text, as it verifies the encrypted payload. If a signature scheme with associated data is used, the signature MUST also verify the envelope and header.¶

Some difficulty is present in the question whether or not the header needs to be present in plain text, or may be encrypted. Encrypting would expose less meta information to observers, but limits the operations possible on the extent.¶

1. For streaming purposes, the extent size MUST be in plain text. At authoring time, it cannot be known which node uses which mode of data transfer, so mandating this field to always remain in plain text is only prudent. This information is also not particularly sensitive, as it provides few clues to the extent contents.¶
2. The current extent identifier MUST also be in plain text. It identifies the extent, and is necessary for any node to determine how to process this data. Extent identifiers may be generated using an algorithm that makes it infeasible to deduce its inputs (see Section 3.5).¶
3. The counter MUST be in plain text. The reason relates mostly to nonce generation and confidentiality (Section 3.8.7). But the tuple of current extent identifier and counter also uniquely identifies an extent version. This permits corretly handling multiple versions of the same extent, thereby permitting old extent payloads to be erased - this is required for the right to be forgotten to be implemented.¶

Given these fields, nodes can process streams of extents, and also make some decisions on whether and how to process them. The remaining header fields are not, strictly speaking, required unless a full resource is to be processed.¶

1. Knowledge of the previous extent identifier permits ordering individual extents into a single resource (Section 3.5.1).¶
2. Knowledge of the author identifier permits verifying that a public key based signature over the extent was created by the same public key as referenced via the author identifier.¶

If the private header flag is set in the version tag, these additional header fields MUST be encrypted. Otherwise they MUST remain in plain text.¶

3.8.1. Hash Functions

A cryptographically secure hash function is required for creating version tags, extent identifiers and author identifiers, and may be used in other constructs. Implementations Implementations MUST support the following algorithms:¶

Key pairs where the public key is small enough to reasonably fit into the author identifier field do not require hashing for creating collision free identifiers. Implementations MUST support this none hash function, which simply returns its input value.¶

Implementations MUST provide the SHA-3 family of hash functions, and the none function. The SHA-2 family of functions MAY be provided.¶

3.8.2. Public/Private Key Pairs

There is no particular reason for this specification to require the use of any specific public/private key pair type, as keys are only indirectly used here. However, the keys may be used for asymmetric signatures as described in Section 3.8.3, and for key exchanges building upon this specification or developed alongside it.¶

Implementations MUST only support key pairs for which asymmetric signature algorithms are defined. Furthermore, implementations SHOULD only support such key pairs for which key exchange algorithms are defined.¶

Only the asymmetric signature algorithm (Section 3.8.3) is included in the version tag, so specifying the key pair used directly is not required.¶

3.8.3. Asymmetric Signature Algorithm

As outlined above, Vessel requires support for asymmetric signature algorithms .¶

Implementations MUST provide the PureEdDSA functions based on edwards curves. DSA and RSA functions SHOULD be provided for compatibility with existing security standards.¶

3.8.4. Message Authentication Codes

The following message authentication codes are defined for use in MAC sections (Section 3.4.5.2).¶

Note that the section payload is the resulting code only, which also means the section size depends on the algorithm selection in the version tag. Any nonces or keys used in computing the MAC MAY be encapsulated in appropriate sections in the authentication topic (Section 3.4.4.1), but this is out of scope for this specification.¶

Some MAC algorithms require a nonce. Implementations MUST either provide a unique nonce per extent as required by the algorithm, or provide a unique key per extent if the algorithm has no nonce requirement. See Section 3.8.7 for details.¶

Implementations MUST provide the Poly1305 based algorithm, and SHOULD also provide the KMAC functions.¶

3.8.5. Symmetric Encryption

For encrypting the extent payload, we require symmetric stream ciphers that SHOULD NOT impose any expectation that the plain text is a multiple of some block size in length. This is because extent sizes are multiples of page sizes, and extent metadata occupies some of that space.¶

It is in principle possible to select this metadata size such that the payload size is divisible by some stream cipher's block size without remainder. Implementations MAY provide such a specific selection of algorithms, and thus permit additional stream ciphers. However, implementations MUST NOT permit the selection of such stream ciphers without taking precations with selecting the metadata size as above.¶

The list contains only authenticated encryption algorithms with associated data (AEAD). The rationale for this is in Section 3.7. These algorithms require a nonce per extent; see Section 3.8.7 for details on this.¶

As these are AEAD modes, the extent signature is provided by the AEAD algorithm's authentication tag. See Section 3.8.6.¶

Implementations MUST provide the ChaCha20 implementation. AES-based AEAD SHOULD be implemented as well, but may be omitted.¶

If the special identifier none is chosen, there is no encryption and no confidentiality.¶

3.8.6. Signature Algorithm

The signature algorithm is a reference to other algorithms specified in the version tag hash; its identifiers therefore are not algorithm identifiers as such, but reserved words that refer to another algorithm identifier.¶

Extents can be authenticated via the signature, and additionally extent payloads may be confidential. If confidentiality is provided, the authentication is already part of the AEAD algorithm used. If confidentiality is not provided, signatures may either be provided by a message authentication code or an asymmetric signature. All extents MUST include a signature.¶

3.8.7. Nonce Generation

There are a number of attacks possible when keys - for message authentication or confidentiality - are re-used across multiple extents. In order to mitigate against these, some MAC algorithms and all AEAD algorithms listed in the previous sections require the use of a nonce. This permits sharing a key across multiple extents. The only requirement is that the nonces MUST be unique per extent.¶

Unlike the key, they do not themselves have to be confidential. That means we can derive a nonce from public metadata of the extent. The envelope is not particularly unique here, however, the current extent identifier and authoring counter in the public header together serve to identify a unique extent version.¶

[RFC8439] requires 96 bit nonces, which [RFC5116] also recommends. The latter also suggests using a fixed nonce prefix as well as a variable counter to construct the nonce. That is exactly what the current extent identifier and authoring counter provide.¶

Their length, however, depends on the algorithm choices. To make them more predictable, we will hash their concatenation, and truncate the result to 96 bits (12 octets).¶

inputs = current_extent_identifier | authoring_counter

hash = nonce_hash(inputs)

nonce = truncate(hash, 12)

unique_key = nonce_hash(shared_key | nonce)

4.1.1. In Scope

Connectivity:

By addressing storage independent of transport, Vessel observes the end-to-end principle, and does not require any specific functionality in middle-boxes.¶

Reliability:

Vessel separates content into extents, each of which constitutes a fully defined Vessel document. Vessel organises extents in such a way that partial availability of extents does not negatively impact the ability to process those that are available (although encapsulated data may not have that same quality). Furthermore, extent authoring by multiple sources is conflict-free.¶

Content agnosticism:

Vessel is fully content agnostic and treats data as opaque binary objects.¶

Heterogeneity Support:

Part of the goal of subdividing data streams into extents was to permit heterogeneous devices to participate in manipulating them, as extents limit e.g. memory and bandwidth requirements. Similarly, no specific constraints are placed upon transfer protocols, allowing heterogeneity also here.¶

Integrity:

Vessel contains provisions for ensuring the integrity of encapsulated data.¶

Authenticity:

Vessel extent contents are always authenticated.¶

Confidentiality:

Vessel extent contents may be encrypted; the format provides for facilities to achieve that.¶

Privacy:

Vessel provides anonymous modes of operation and data confidentiality, which together specifically address [RFC6973], Section 5.1.2.¶

Censorship resistance:

Censorship resistance is difficult to achieve within Vessel itself. Extents contain identifiers, which can be used to filter content either if the transport protocol itself does not provide confidentiality. Similarly, middle-boxes could be used to filter content. However, censorship resistance is one reason why the design of Vessel explicitly eschews content hashes as extent identifiers. As a result, censorship can be circumvented simply by generating a new identifier for the same content.¶

Outcome Transparency:

If these specifications do not provide for outcome transparency, that SHOULD be considered reason for an amendment.¶

Adaptability:

Adaptability is one of the major concerns of Vessel, being a content agnostic container format. A reason for subdividing content into self-contained extents was to make the format more easily usable in streaming applications, as well as persistent data storage.¶

Decentralization:

The multi-authoring capabilities of Vessel aim at decentralized uses. Extents belonging to the same data stream can be created independently by multiple authors, synchronized, and brought into eventual consistency. If no synchronization occurs, multiple diverging versions can be maintained independently of each other.¶

Remedy:

Remedy (new in [I-D.draft-irtf-hrpc-guidelines-13] often stands in stark contrast to anonymity and pseudonymity, both of which are out of scope. That is, it will be difficult to seek remedy against anonymous use that is abusive. However, another consideration in the design of Vessel is the [GDPR], specifically the "right to be forgotten". A leading consideration in generating extent identifiers independent of content is that content can also be replaced and deleted as a result. This stands in stark contrast to approaches using content hashes as identifiers, which favour immutability of content.¶

Open Standards:

Care has been taken to define this specification in reference to other open standards (see the references section).¶

4.1.2. Out of Scope

Internationalization:

Vessel treats data as opaque binary objects, and thus permits internationalization of such data, but does not explicitly support it.¶

Localization

The resource format is intended for processing by computers; localizing the name of each field is the concern of an application displaying this data.¶

Security:

[BCP72] lists data transfer (i.e. protocol) considerations that are not in scope for Vessel. Furthermore, it enumerates concerns regarding the handling of cryptographic keys. Vessel itself is agnostic to such mechanisms, but may nonetheless be used to carry related information. Some suggestions on this are provided, but security as per [RFC8280] is, strictly speaking, out of scope.¶

Pseudonymity:

Identifiers in Vessel are not tied to any personally identifiable information, and can be entirely ephemeral. It is up to applications using Vessel to ensure pseudonymity concerns.¶

Anonymity:

As with pseudonymity, anonymity is an application concern. However, this document enumerates some in Section 4.4.¶

Accessibility:

Being content agnostic, Vessel permits accessibility concerns being addressed in applications, but does not provide any facilities for it.¶

4.3.1. Confidentiality

Vessel extents are designed with confidentiality in mind, but may be used without such features. This is desirable in a container format, as information contained within may also be disseminated to the public.¶

The approach to confidentiality is based on current best practice AEAD algorithm choices from [RFC8439] and [RFC5116], and follow the suggestions in those documents.¶

4.3.2. Data Integrity

Data integrity is provided via a mandatory signature over the entire extent. This may be provided in the form of an AEAD authentication tag, in which case all unencrypted extent data is included in the associated data. Alternatively, MAC or asymmetric signature algorithms are provided for non-confidential extent payloads.¶

4.3.3. Peer Entity Authentication

In the context of Vessel, peer entity authentication may better be referred to as data origin authentication. In either case, the mandatory extent signatures are always keyed. This requires both origin and recipient to previously perform some kind of key exchange.¶

While the key exchange itself is not in scope of this document, on the assumption that it has occurred, it is possible to verify the data origin. Particular attention is given to subtler attacks when confidentiality is also used (see Section 3.7.3).¶

4.3.4. Non-Repudiation

Non-repudiation is desirable, but out of scope of this document largely because key exchange is out of scope. This specification presumes that the validity of keys is established before attempting to use them.¶

4.3.5. Unauthorized Usage

Authorization is generally outside of the scope of this specification, as it effectively relates to the problem space of key exchange, validation, etc.¶

However, some authorization concerns can be discussed. As the container format is specifically designed for multi-authoring purposes, authorization concerns must raise their head.¶

1. Read authorization is effectively granted by either¶
2. Providing the extent payload in plain text, or¶
3. Initiating a key exchange for the encrypted payload, which is itself out of scope.¶
4. Write authorization is less of a question of permitting authorship; any entity can generate a key pair and start authoring extents for a resource. Rather, it becomes a question of which authors are considered trustworthy enough to be included in the resource.¶

As the origin extent identifier is randomly generated, there is nothing stopping an attacker from re-using the same origin extent identifier for a competing resource. For a reader to verify the correct origin extent has been received is then a queston of accepting or rejecting the origin extent's author. This is out of scope of this specification. However, implementations using Vessel MUST take care to establish the origin extent author's trustworthiness.¶

With trust in the origin extent established, it is prudent to trust only those authors of additional extents that the origin extent author explicitly authorizes. Such a scheme is outside of the scope of this document; however, the AAA topic (Section 3.4.4.1) is specifically reserved to encapsulate such information.¶

Given an appropriate authorization scheme and a verified origin extent author, nodes can identify unauthorized extents, and MUST reject them as not belonging to the same resource.¶

4.3.6. Inappropriate Usage

Any scheme that prevents unauthorized use may also be extended to prevent inappropriate use. As above, these schemes are out of scope.¶

4.3.7. Denial of Service

It is feasible to treat the generation of extents that are not authored by authorized users as a kind of denial of service attack. It certainly consumes resources on the recipient's side.¶

Most such "denial of service" mitigation is out of scope for the reasons previously mentioned. However, an authorization scheme that is transported within Vessel extents itself may also permit nodes from understanding the authorization state of a resource without being privy to encrypted extent payloads. Such nodes SHOULD not relay extents to further recipients that they can already reject as unauthorized, thereby limiting the spread of the denial attack.¶

4.3.8. Replay Attacks

Replay attacks are not inherently damaging to Vessel; an extent may be received multiple times. The complete resource de-duplicates this via the extent ordering scheme described in Section 3.5.1.¶

However, appropriate countermeasures against a node transmitting an extent multiple times SHOULD be implemented near the transport layer.¶

4.3.9. Message Insertion

Message insertion is largely equivalent to the unauthorized use case described in Section 4.3.5, and mitigation against it therefore the same.¶

4.3.10. Message Deletion

The extent ordering scheme in Section 3.5.1 is deliberately designed to enable both handling of partial trees as well as deterministic merging of them afterwards. Message deletion in the sense of extent deletion therefore is mitigated against.¶

There is, however, some interaction with unauthorized use. Assume a reader wishes to join the live stream of a resource at the current time point. If this extent is not authored by the same entity as the origin extent, it will be difficult to establish trust in it; attackers may exploit this.¶

To exploit this, an attacker must be a man-in-the-middle. They must receive extents from upstream, and scan them for authentication information. They must then delete - i.e. not pass on - the extent containing such information. The downstream recipient now has two resource subtrees to deal with, one from the origin to this deleted extent, and one following the deleted extent. An attacker may use this deletion attack to then launch an insertion attack, and fake the entire subtree following the deleted extent.¶

Within Vessel itself, it is not possible to mitigate against such an attack. This is in scope of a transport protocol, however. Simple transport encryption via TLS and establishment of trust in the sending node mitigates the man-in-the-middle scenario, however.¶

If it is not possible to establish trust in the sending node in this manner, protocol implementations MUST take care to securely transmit authentication data out of band of the extent stream.¶

4.3.11. Message Modification

The mandatory signature algorithms should be sufficient mitigation against message modification.¶

4.3.12. Man-In-The-Middle

A conceivable man-in-the-middle scenario is discussed in Section 4.3.10; otherwise, as Vessel is not a networking protocol, the kind of attack does not easily apply.¶

4.3.13. Key Usage

Vessel relies on secure key exchange outside of its own specification. More precisely, it assumes that:¶

1. Public keys are exchanged, and mapped to author identifiers.¶
2. Encryption and MAC keys are exchanged as necessary.¶
3. The latter are updated regularly; see [I-D.draft-irtf-cfrg-aead-limits-05] for usage limits.¶

Each of these exchanges can be mapped into extent sections in the reserved AAA topic (Section 3.4.4.1), but such a mapping is not in scope of this document.¶

Nonces are, where they are used, derived from public extent metadata. This is consistent with the MAC and AEAD constructs referenced in this document, and should not pose any security risk.¶

4.4.1. Surveillance

The surveillance concers outlined in [RFC6973] specifically relate to network protocols; Vessel is not such a protocol.¶

It is in the nature of a storage format that it applies to files, which may be duplicated and analysed at leisure. Vessel can only provide confidentiality.¶

However, it is worth stressing that authoring keys are in no way required to be identity keys, that is, keys intrinsically tied to a person. They may be ephemeral keys, and rotated at will in order to mitigate some surveillance measures. This interacts with key exchanges (which are also out of scope), as well as the attack described in {#sec:security-considerations-message-deletion}.¶

The consequence of this is that implementations adopting this format SHOULD take care to make authoring keys last only as long as necessary.¶

Besides efficiency in memory and storage mapping, the fixed sized extent was also chosen to mitigate against some kinds of "traffic" analysis, whereby the size of extent sequences can be matched against likely content candidates.¶

Using confidentiality and always padding to the same extent size obscures the size of the plain text payload, and makes such analysis harder.¶

4.4.2. Stored Data Compromise

Vessel mitigates against most stored data compromises by offering encrypted extents. Other data, such as key material, is outside of this specification's scope. Implementations MUST recognize that compromised keys may lead to data compromises.¶

4.4.3. Intrusion

In the context of Vessel, intrusion maps neatly onto message insertion ( {#sec:security-considerations-message-insertion}). Vessel attempts to protect against such attacks, but is reliant on up-to-date authorization data at the receiving end.¶

4.4.4. Misattribution

Misattribution in [RFC6973] refers to misattribution to individuals; Vessel has no understanding of individuals. It is possible to create identity key pairs for individuals and use them directly in authoring extent. Such use is strongly discouraged. Implementations SHOULD rather generate authoring key separately, and use a secure channel to get them authorized. Such authorization may require linking them to the identity key, but this is not required by, and not known to Vessel.¶

Authorization and key generation are out of scope for this specification.¶

4.4.5. Correlation

Vessel cannot protect against correlation of any data sent in plain text. When confidentiality is used, it is difficult to glean any information from the plain text that would permit correlation.¶

The main information that can be correlated is in the use of the authoring key. Implementations SHOULD not only regularly generate new authoring keys and undergo re-authorization, but also SHOULD use different authoring keys for different resources.¶

As a result, it will be difficult to correlate any information over longer term usage. Only within the window in which a single authoring key is used can an attacker establish how many extents this author created.¶

Authorization and key generation are out of scope for this specification.¶

4.4.6. Identification

The authoring key is the only public information that can be used to identify a user. As explained in the previous sections, authoring keys should not be used over a long term. This also thwarts identification by providing less data to link to the same user.¶

As far as personal identifiable information (PII) is concerned, the [GDPR] requires that such information can be deleted (right to be forgotten). This is the reason why extent identifiers are not based on content, but on position in the resource stream. This permits modifying the content in a later version of the same extent, which includes deleting content.¶

Note, however, that the extent identifier and authoring key are strongly linked. An updated extent must be authored by the same authoring key. If applications wish to support this right to be forgotten, they MUST store outdated keys until all of an extent payload has been deleted, and the extent is empty.¶

4.4.7. Secondary Use

Secondary use concerns are not in scope of this document.¶

4.4.8. Disclosure

As Vessel is a storage format rather than a network protocol, the threat model assumes attackers have easy access to extents. Any disclosure related concerns are authorization concerns, which are largely out of scope for this document except as discussed in {#sec:security-considerations-unauthorized-usage}.¶

4.4.9. Exclusion

Exclusion is a network protocol consideration, and does not apply to Vessel. It is strongly recommended that transport protocols consider this issue.¶

Consider a transport protocol that permits subscribing to a resource. As new extents get created, the node creating them may advertise their creation to subscribers immediately. It is feasible for an attacker to deduce from such advertisments when an author is both actively creating and/or attached to the internet in some fashion.¶

Transport protocols SHOULD consider batching advertisments or delaying them to thwart such analysis.¶