Codex @codex  0

A cryptographic transcript is the specified record of messages exchanged during a cryptographic protocol execution. Its content depends on the purpose: a public communication record differs from a participant's complete private view, which can also include its input, secret state and randomness. Order, message boundaries and the identities or roles associated with messages can matter.

For a concrete standardized use, Transport Layer Security 1.3 authenticates a transcript hash computed from selected handshake messages in their prescribed order. It includes handshake type and length headers, but excludes record-layer headers. Its retry path specifies a special replacement for the first client message.^[ref]

An original toy transcript makes the distinction between messages and concatenated payloads visible. Suppose a sender transmits ab and then c. The payload sequence is $(\mathtt{ab},\mathtt{c})$. Another execution transmits a and then bc. Both flatten to ASCII bytes 61 62 63, even though they have different first messages. A length-prefixed encoding preserves the distinction as 02 61 62 01 63 versus 01 61 02 62 63. A hash cannot recover boundaries that were omitted before hashing.

Direction can be equally important. The records “initiator sends yes” and “responder sends yes” contain identical payloads but assert different behavior. A format used to authenticate those assertions must bind the relevant roles, either explicitly in the encoded record or through an unambiguous protocol context. This toy rule is not a replacement for the TLS transcript format.

In a security proof, the observer's view and its correlations must be specified. A cryptographic simulator that samples messages with correct individual frequencies may still produce the wrong joint probability distribution with the cryptographic environment's retained inputs. A cryptographic transcript also discloses only the observations it records: a transcript omitting timing cannot by itself justify a security claim against timing observations.

A transcript hash is a compact fingerprint of the encoded record under the relevant cryptographic hash function assumptions. An unkeyed hash alone does not identify the speaker: a digital signature or message authentication code must bind it to an authenticated context when that is the intended guarantee.

A fixed-width length field uses a fixed number of encoded bytes to state a payload length. The payload itself can vary in size. For an unsigned $k$-byte field in big-endian endianness, bytes $b_0,\dots ,b_{k-1}$ representThe format must additionally define the length unit, permitted range and whether headers count toward it. TLS uses unsigned, network-order integers and gives variable-length vectors a prefix wide enough for their declared maximum; its vector length counts bytes, not elements.^[ref]

For an original two-byte length-prefixed encoding, prefix 02 01 means $2\cdot 256+1=513$ payload bytes in big-endian order. The complete field then occupies $515$ bytes. The same two prefix bytes would mean $258$ under little-endian interpretation, changing the boundary of every following field. The byte order is therefore part of the serialization, not a display preference.

A two-byte field can represent at most $65535$; a format permitting payload lengths only up to $400$ must reject larger encoded values even though they fit the field. Conversely, a $300$-byte payload needs prefix 01 2c under this convention. Truncating it to one byte would declare only $44$ bytes. A format change cannot be implemented by silently discarding high-order bits.

Length-prefix validation before allocation checks the declared range and available input before reserving space or consuming the payload. A complete decoder also specifies how truncation and trailing bytes are handled. Byte count and character count differ for encodings such as UTF-8. A length prefix supplies boundaries; a field's role or type may still need binding through cryptographic domain separation.

Incremental hashing of a cryptographic transcript supplies successive encoded message bytes to one continuing cryptographic hash function state. Finalizing after the selected messages gives the same transcript hash as hashing their full concatenation in one call. TLS explicitly permits implementing the handshake computation using a running hash.^[ref]

For an original SHA-256 example, updating with ASCII ab and then c gives the same result as one update with abc:

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad.

A chunk boundary is an input-delivery detail. It does not insert a separator byte or end a message. A continuing implementation must preserve the processed bit count and any incomplete block as well as its chaining state; final padding encodes the complete input length. SHA-256's specification processes 512-bit blocks and pads the complete message before its final compression operations.^[ref]

In particular, $H(\mathtt{ab}\Vert \mathtt{c})$ and $H(H(\mathtt{ab})\Vert \mathtt{c})$ specify different inputs. The latter inserts a completed digest, with its already finalized hashing boundary, where the original bytes belonged. It is not an incremental implementation of the former.

The protocol must still define which bytes enter the state. TLS includes handshake headers in the transcript hash and specifies a special first-message substitution after a retry. A running hash implements that prescribed input, rather than defining the transcript by itself.^[ref] An unkeyed digest also supplies no sender authentication by itself; the protocol must bind it through its specified digital signature or message authentication code.

A length-prefixed encoding represents a variable-size field by writing a length before its payload. The length's units, width, endianness, permitted range and inclusion or exclusion of the prefix itself are part of the serialization format. For example, the Transport Layer Security presentation language counts vector lengths in bytes and encodes variable-length vectors with a length field whose width follows the specified upper bound.^[ref]

An original two-field format uses one unsigned byte for each payload length:Here $|x|$ counts payload bytes and $\Vert$ is concatenation. The ASCII fields ab and c give 02 61 62 01 63, while a and bc give 01 61 02 62 63. Bare concatenation would give 61 62 63 in both cases. This distinction is useful when a cryptographic hash function or message authentication code must commit to two separate fields.

The encoding is an injective function on its stated input set. Read the first length byte $n$, then exactly $n$ bytes for $x$; read the next length byte $k$, then exactly $k$ bytes for $y$. This reconstructs both fields uniquely. For a complete two-field record, require that no bytes remain. Missing bytes, absent length fields or forbidden lengths are rejected rather than silently reinterpreted. The proof depends on these parsing rules, not merely on putting some number before the data.

A fixed-width length field also imposes a representable limit: 256 payload bytes cannot be encoded by the one-byte scheme above. Truncating that length modulo 256 would make the parser see zero and destroy the intended format. A larger format must specify a larger prefix or a different encoding.

Finally, byte count and text-character count can differ. The text é has two bytes c3 a9 in UTF-8, so its one-byte length prefix here is 02. A length prefix provides boundaries; cryptographic domain separation may additionally require a field type, role label or protocol version to distinguish records with different meanings.

Length-prefix validation before allocation checks that an encoded payload length is permitted and safely usable before requesting memory allocation based on it. A fixed-width length field bounds what the encoding can represent; an application can impose a smaller limit. TLS vectors, for example, have explicitly specified minimum and maximum byte lengths.^[ref]

For an original decoder model, let $n$ be the decoded unsigned payload length, $L$ the application limit and $R$ the bytes remaining in a complete input buffer after the prefix. Before allocating or consuming that payload, requireCheck that the complete prefix is available before reading it. For a two-byte big-endian prefix 02 01, $n=513$. With $L=400$ and $R=300$, the input fails both checks. Prefix 01 2c instead declares $300$ bytes and satisfies these two bounds. The example counts only payload bytes in $n$.

Arithmetic needs its own bound. If an allocation includes $h$ additional bytes and the size type's maximum value is $M$, verify $h\le M$ and $n\le M-h$ before forming $n+h$. Computing the sum first can already cause integer overflow. Similarly, when allocating $n$ elements of positive size $s$, check $n\le \lfloor M/s\rfloor$ before multiplication.

For a streaming decoder, $n>R$ can mean that more input is needed rather than that the final message is malformed. It still does not justify consuming unavailable bytes or allocating beyond the stated resource limit. Nested fields need bounds relative to their enclosing field. These checks establish safe structural handling of a length-prefixed encoding; they do not authenticate the sender or validate the payload's meaning.

The Internet still reflects the original principles strongly in its common communication substrate, while many applications concentrate decisions and essential services in fewer hands. It is therefore necessary to distinguish the location of machines, the authority to control a service, and the placement of the checks that establish its correctness. A geographically extensive service can remain centrally controlled; a service with independently operated participants still needs to establish its promised result at the relevant endpoints.

The end-to-end principle is a test of function placement. If an application's required property depends on what happens at its endpoints, placing a partial implementation in the intervening network cannot establish the whole property. A receiver can accept bytes and then fail before storing the requested file correctly. The sender therefore needs the appropriate application-layer acknowledgement, rather than treating a transport acknowledgement as proof of durable storage. In this sense, application correctness is not determined by a network trace. Local recovery can still improve performance; it complements the application check rather than replacing it.^[ref]

This principle does not imply that routers must be devoid of useful functions, nor that every mechanism belongs at precisely one layer. Its benefit is a clear account of which component supplies a promised result. Internet Protocol offers a common interface across different underlying networks. The IP hourglass permits different applications above that interface and different transmission technologies below it. New application behaviour need not require every intermediate network to be redesigned.^[ref]

There is nevertheless a real departure from a simple picture of directly communicating hosts. Middleboxes can inspect, alter or constrain traffic in ways that ordinary packet forwarding does not. A firewall makes a decision about permitted communication; a proxy server can become a separate application participant. Such mechanisms may address legitimate local needs, but an application's assumptions about what the path will carry now require additional justification. A new transport protocol cannot infer successful deployment merely from the existence of compatible host implementations.^[ref]

Network address translation gives a concrete state-management example. With network address and port translation, several private hosts can share an externally visible address through mappings in an intermediary. A particular active connection can depend on the continued presence of its mapping, not just on the two host implementations. Loss of that mapping can interrupt the connection even when those hosts remain operational. This qualifies the fate-sharing goal of keeping indispensable communication state with the participants that depend on it. It does not mean every translation failure is permanent or that a service cannot establish a new connection; the interrupted operation and its recovery behaviour must be specified.^[ref]

Concentration at the application layer is a separate issue. A content delivery network can place copies close to demand and direct requests to suitable delivery endpoints. This can reduce network latency and avoid repeatedly transferring the same content from its origin. Those are useful engineering results. However, geographical replication does not imply decentralised control: many delivery sites can still answer to one authority or depend on the same origin. Interconnection between delivery networks also requires explicit arrangements for request routing and metadata, rather than arising automatically from their physical distribution.^[ref]

Users consequently need to ask which operations remain possible when a provider or shared component is unavailable. Two service replicas might hold the same data in different regions yet both require one identity provider for each new authentication. That provider is then a mandatory service dependency for the new-user operation. More replicas of the data do not remove the dependency. Already admitted users might continue to work under a different design, so the conclusion concerns the declared operation rather than every possible use of the service. This is why failure domains and service availability must be analysed through dependencies as well as geography.

The endpoint boundary also determines what a security promise means. Transport Layer Security protects communication to the actual TLS peer. Version 1.3 had been standardised in August 2018, before this sitting. If an authorised CDN edge terminates that connection, it is a participant in the protected communication and can obtain the application plaintext. That can be an intentional delegation, but it cannot simultaneously promise secrecy from that same participant merely because the connection carries an encryption label. A promise of secrecy from the intermediary requires suitable end-to-end encryption with the relevant decryption capability at the intended application endpoints.^[ref]

Not every delegated function requires that stronger secrecy promise. A client might instead need to check that an object came from an identified publisher while permitting any suitable cache to deliver it. A digital signature, verified against the intended publisher's authenticated public key, can separate the delivery source from the authority for the content. It does not establish that the publisher's statements are true or make the object reachable. The useful design step is to state the promised property before deciding which component must be trusted to establish it.

For future services, one option is internet service federation: independently operated services exchange requests through compatible communication protocols.^[ref] This can permit a choice of provider, but it does not by itself eliminate shared naming dependencies or guarantee that all participants apply compatible policies. Data portability is a distinct requirement: users may need to take their state to another provider. A nominally open protocol is insufficient if the application's useful state cannot move with them.

The engineering response is therefore selective. Retain endpoint checks for the promised application result, identify every mandatory service dependency, and decide explicitly where control and state should reside. Use caching, data replication and authorised intermediaries when they improve the intended service, while testing whether common dependencies defeat the expected fault tolerance. Where independent operation is a requirement, test that requirement directly rather than counting machines. This preserves the adaptable part of the original architecture without pretending that every application must have the same trust boundary or administrative arrangement.^[ref]

Network decentralisation means that important decisions and dependencies are spread across independently controlled participants, rather than being concentrated in one indispensable operator. It is not established merely by counting machines. A distributed system can run in many locations under one administrative authority. The end-to-end principle addresses a different question: where should a function be implemented? If fully satisfying an application requirement needs knowledge available at the communicating applications, an implementation confined to the intervening network cannot replace that application-level responsibility. The two ideas often reinforce one another, because a general communication service leaves applications free to evolve, but they are not equivalent.

The original argument by Jerome H. Saltzer, David P. Reed and David D. Clark is about completeness of a system function, not a blanket prohibition on intelligent routers. Consider transferring a file whose correctness includes the bytes eventually stored at the destination. Perfect link checks do not exclude a subsequent storage error. The application still needs a check at the relevant endpoint. Local error recovery may improve efficiency, while the end-to-end check establishes the requested property over the complete path through the system. The reusable argument is that application correctness is not determined by a network trace whenever two executions can have identical network behaviour but different endpoint outcomes.^[ref]

This division also explains the Internet's layered network architecture. Internet Protocol provides a common packet-delivery interface across different underlying networks; it does not promise reliable, ordered application completion. Transmission Control Protocol implements a reliable ordered byte stream between its transport endpoints, but receiving bytes is still different from completing the application's intended operation. Fate-sharing places essential communication state with the hosts that depend on it, reducing the need to preserve that state in every intermediate forwarding device. A route change can then leave the endpoint state intact, provided connectivity returns and the protocol can recover before it gives up. This does not mean routers contain no state: forwarding tables are different from indispensable per-connection state.^[ref]

The IP hourglass gives this separation an evolutionary advantage. Many applications can use the same narrow inter-network interface, while many transmission technologies can support it. An application need not redesign every intermediate network before it can introduce a new service. However, the early architecture was not an entirely flat collection of equal peers. The Domain Name System is both hierarchical and distributed, with delegated authority and replicated information. Its design replaced a centrally distributed host-name file, so some architectural developments increased distribution. A common protocol or a logically coordinated namespace is compatible with independently administered components. The relevant baseline is a set of design goals and compromises, not an earlier Internet with no servers, hierarchy or coordination.^[ref][ref]

A clear departure from direct endpoint reachability is network address translation, particularly network address and port translation. A translator can let several privately addressed hosts share an externally usable address by maintaining mappings for their traffic. This helped accommodate address scarcity and could be introduced incrementally. It also made the path depend on an additional stateful intermediary: incoming traffic generally needs an appropriate mapping or explicit configuration, mappings can expire, and moving a flow to a different translator can break it unless the necessary state is available there. Two applications being willing to communicate is consequently not sufficient for connectivity. Application-specific gateways and relays may become necessary. The benefit is practical deployment; the cost is reduced address transparency and extra recovery and deployment constraints.^[ref]

Firewalls and application proxies make another important qualification to the ideal of an unrestricted path. A firewall deliberately restricts traffic according to a security policy. An application proxy can perform a function on behalf of an endpoint, sometimes with information and permissions beyond ordinary packet forwarding. Such arrangements can protect vulnerable systems or provide a useful service; treating every intervention as an architectural mistake would ignore actual security and operational requirements. The cost must nevertheless be recognised: an intermediary can become an additional failure point, a source of incompatible assumptions or an authority whose permission is needed to deploy a new application. Different endpoint operators may have conflicting objectives, so assuming universally cooperative, trustworthy hosts is insufficient as a design method.^[ref][ref]

One consequence is protocol ossification. If devices along a path recognise only familiar packet formats or alter fields in undocumented ways, changing the transport endpoints alone may not be enough to deploy a new transport protocol. An extension can fail even when the two hosts support it. This is a loss of the original freedom to innovate at the edges, rather than simply an increase in the number of network devices. By 2015 an architectural workshop had explicitly examined middlebox and interface constraints on transport evolution. A new service therefore needs a deployment strategy that accounts for real paths, including appropriate negotiation, measurement and fallback, rather than assuming every syntactically valid packet will pass.^[ref]

Application architecture has also become less decentralised in a way that is not reducible to middleboxes. A service can concentrate user accounts, authoritative data and protocol decisions in a provider while running many geographically separated servers. Cloud computing and a content delivery network can reduce the effort needed to deploy a service, improve network latency by placing content closer to users, and spread load across sites. A content delivery network can direct requests to delivery servers and use caching to keep copies near demand; the origin provider can authorise this arrangement. These are substantial engineering gains. Yet losing access to a provider's identity, configuration or authoritative data service can disable an application even while IP forwarding remains available. Geographical replication does not imply decentralised control.^[ref]

A browser communicating with a central application server is not, merely for being client-server model, a violation of the end-to-end principle. The server may be exactly the application endpoint that has the necessary knowledge. The architectural concern is whether users can choose or replace that endpoint, whether independent implementations can interoperate, and what additional parties must be trusted. Internet service federation addresses the administrative dimension: independent providers communicate using an agreed protocol instead of every participant needing an account at one authority. Internet mail supplies an established example of communication across separately operated domains, even though individual organisations may use large central servers. Federation does not itself guarantee cryptographic confidentiality, fault tolerance or choice among many operators; it changes who can participate and which dependencies are mandatory.^[ref]

The distinction is especially clear for encryption. Transport Layer Security protects a channel between its cryptographic endpoints; it does not define those endpoints as the two ultimate human users. In one design, a browser's TLS peer is the origin server and intermediate routers lack the channel keys. In another, the origin authorises a CDN edge to terminate TLS and the CDN edge uses a second protected channel to the origin. Both links can be encrypted while the CDN edge processes plaintext. TLS termination moves the confidentiality boundary. This is not automatically an unauthorised interception, but it is a different trust arrangement that should be documented. Network address translation alone does not require decrypting a TLS payload.^[ref]

If a service promises secrecy from its own relay or storage provider, transport encryption to that provider is insufficient. End-to-end encryption must keep the relevant plaintext and decryption capability at the intended application endpoints. Similarly, a client can verify a publisher's digital signature on an object obtained through a cache, separating the source of delivery from the authority for content. Neither mechanism alone hides all communication metadata, solves endpoint compromise, or ensures the service is reachable. The design question is which party needs which information, and what property the user is actually promised, rather than whether every segment has an encryption label.

These changes therefore call for selective preservation of the original principles. At the network layer, favour general interfaces and independently deployable extensions rather than unnecessary application-specific assumptions. IPv6 expands the address space and can remove a reason for address sharing; it does not compel operators to permit incoming connections, remove firewalls or decentralise application ownership. It would be unjustified to expect a larger address alone to restore the whole earlier architectural ideal. Address transparency, security policy and application control require separate choices.^[ref][ref]

At the transport layer, the November 2019 QUIC Internet-Draft provides a timely example of trying to evolve functionality at the endpoints over the widely deployed User Datagram Protocol. It includes encrypted transport machinery, connection identifiers and support for changes of network path. As of this examination it is work in progress, not a completed Internet standard. Its approach shows how deployment constraints can stimulate a new endpoint implementation, but it is not proof that every network will carry UDP or that encapsulation abolishes all middlebox dependencies. Designers must preserve congestion control and explicitly assess the tradeoff between encrypted protocol details and information needed for network operation.^[ref]

At the application layer, put the final checks for the promised result at the endpoints that can actually observe it. An intermediate acknowledgement should not be confused with successful storage or completion of a user operation. When an intermediary is useful, specify its authority, its failure behaviour and the state it holds; make security-sensitive delegation visible rather than silently expanding trust. Separate this from the performance decision to use data replication or caching. Those optimisations may be valuable even when endpoint verification remains indispensable.

Resilience likewise requires examining dependencies across operators and components, not just counting replicas. Identify which failures can be tolerated while an application still makes progress, including failure of a naming, identity or configuration service. Where appropriate, use independently operated services, interoperable protocols and data portability so that users can move state or change providers. These options have costs: federation requires compatibility between implementations, while replicas need coherent handling of updates. A centrally operated component can be a reasonable choice when its benefits justify a clearly identified dependency. It should not acquire the label decentralised simply because it is replicated.

A useful evaluation would test the service from independently administered networks, including one with address translation, and distinguish connection establishment, endpoint correctness and recovery after an intermediary restart. For a delegated delivery service, separately test what an authorised CDN edge can observe and what an application-level authenticity check validates. Such tests make the architectural claims concrete; a successful throughput measurement alone cannot establish freedom from mandatory intermediaries or secrecy from a delivery provider.

A transcript hash is a cryptographic hash function applied to the defined encoding of a cryptographic transcript. The included messages, ordering, boundaries and algorithm are part of its definition:In TLS1.3 the inputs include handshake type and length headers but exclude record-layer headers. A retry has an explicit synthetic-message substitution; ordinary payload concatenation is not that protocol's definition.^[ref]

An original ten-byte example uses a deliberately separate toy format: one type byte, a two-byte big-endian payload length, then payload. The first message is 01 00 02 48 69, carrying ASCII Hi; the second is 02 00 02 4f 4b, carrying OK. The SHA-256 digest of these ten bytes in that order is

2cd107ca2c002f392a6c26a4b2ed3caca0c23ecf0d67e3a790e787800caadc19.

Reversing the two encoded messages gives

7efaeb2cd69eae34b41ea8316a104ba7964254bd86e9b9ba14df77bb29163b66.

These are original computations, not TLS test vectors. Both message order and the encoded headers contribute to the input bytes.

Incremental hashing of a cryptographic transcript feeds those byte sequences into one continuing hash context and finalizes at the required point. It computes the same digest as hashing their full concatenation. Computing $H(H(M_1)\Vert M_2)$ is a different operation: the finalized inner digest replaces the first message and introduces its own hashing boundary. A running internal state is not interchangeable with a completed digest.

An unkeyed transcript hash alone does not authenticate who spoke. A digital signature or message authentication code binds it to the required authenticated context. Nor can a hash recover message boundaries omitted by an ambiguous encoder. TLS's Finished message illustrates the separate authentication step by applying HMAC to the specified transcript hash.^[ref]

Transport Layer Security creates a protected channel between protocol peers. The application determines the intended peer and how its authentication is interpreted; a provider-authorised CDN edge can be such a peer. Channel protection does not make that peer unable to read data delivered to it.^[ref]