xaptum / xtt-spec

Working draft for the XTT RFC

XTT 1.0 Draft Specification

This is the working area for the draft of the XTT 1.0 protocol.

Building The Draft

You will need make, kramdown-rfc26291 (https://github.com/cabo/kramdown-rfc2629), and xml2rfc (https://xml2rfc.tools.ietf.org/).

Run make lib/main.mk to initialize the git submodules.

Run make to render the *.txt and *.html formats.

xtt-spec's Issues

Rethink server ID

We've talked about this a lot for a while, but I think this should be discussed in earnest here.

The intention of the server ID was to ensure that the specific server machine a client connects to is the one it intended to connect to. It was inspired by TLS libraries that take pains to make sure the responder is the intended URL, and not simply a different machine whose credentials can be validated using a trusted root.

However, this now seems antithetical to the usage of XTT: the client connects to a decentralized "server" and any machine that acts on behalf of that "server" must have a valid credential under the root that represents the "server". The client doesn't care which specific machine it connects to, only that it is an authenticate member of the "server" (i.e. its credential is signed by the correct root).

Retaining the server ID:

• Adds size to the message
• Requires extra processing on the client side
• Most importantly, is a burden on the user of the client software, to have to manage a server ID

Update spec to reflect record-layer-like header

We want to use a constant header format for all messages (both handshake and session), to both ease parsing and allow for long-message framing.

This means the header should include the total-packet-length in a static location (to ease parsing), even for handshake messages whose structure and length are known.

It should also include framing info (e.g. frame number, total frame count). Cf. the (D)TLS specs for inspiration.

Proposal: do not establish session in identity handshake

The intended lifetime flow for a device looks something like this:

          [First Boot]
                |
                v
       [Identity Handshake]
                | + and *
                v
[Reboot] <--- [Run] ---> [Session Handshake ]
     |         ^ ^               | *
     |         | |               |
     ----------  -----------------

+ Provision identity
* Establish session keys

In the current protocol, session keys are establish during both handshakes. To reduce duplication and simplify the protocol, I propose removing the session key establishment from the identity handshake. Clients will instead need to run both the identity and session handshakes on first boot.

The identity handshake is intended to be run just once in a device lifetime --- one additional handshake is not a significant cost.

Separating these has three big advantages:

• the purposes of the handshakes is made more clear. The first does only identity provisioning and the second does only session establishment.

• the protocol is simplified and duplication is removed. The logic for session key establishment will exist only in the session handshake.

• the flow is simplified, reducing the chances for implementation errors.

Explore nonce-misuse resistant ciphers

In XTT, the sequence numbers are critical to the security of the protocol: it is the assumption that sequence numbers are strictly monotonic that ensures per-packet nonces (for the AEAD protection of packets) are truly unique. Repetition of a sequence number opens up all the concerns of nonce-misuse in symmetric ciphers (e.g. all the CBC chosen-ciphertext attacks on TLS, like BEAST).

Sequence number monotonicity may be tricky for either/both servers and clients:

• (Servers) Due to the fundamental design criterion of XTT that its sessions be independent of transport-layer connections, session state is expected to be shared amongst distributed physical machines. The session sequence numbers are updated on each packet processed, making fault-tolerant sharing difficult.
• (Clients) Client implementations may not properly persist a used sequence number (send a packet -> not save its sequence number -> crash -> reuse that sequence number on restart). This may be compounded by slow access to non-volatile memory on constrained devices. Further, simply using random numbers for the nonce, rather than the sequence-number-based approach we have, is a non-starter considering many devices may have no/poor rng's.

It's hoped that the next generation of ciphers (e.g. the eventual winners of the CAESER competition) will have nonce-misuse resistance designed in. Until that time, though, we have to be careful with the expectations we place on our users with respect to nonce hygiene.

For now, in our (Xaptum's) server implementations, we have to make sure we follow good sequence number hygiene. This probably means something like making the low-order ~16-bits of the sequence number a machine-specific ID, thus ensuring that two machines never use the same sequence number (in the event of a crash, the machine that takes over may still use an old sequence number, but that will simply result in packet rejection and not in compromise of the security).

We should add a recommendation on such sequence number hygiene in the implementation notes of the spec.

For future reference, here are some thoughts on nonce-misuse resistance:

• SIV (Synthetic Initialization Vector) mode of a block cipher to give nonce-misuse resistance
  • = Keyed-hash of message fed in to create IV
  • IV = prf<Key>(nonce | addl-data | plaintext)
    • where nonce is a traditional nonce (maybe random, maybe a counter, maybe screwed up and repeated)
  • No requirement for random numbers, nor to keep state for a counter
  • Same message with same nonce gives same ciphertext
  • If different message, even with no counter or randomness, different ciphertexts
  • "Two-pass" (hash entire message, then AEAD encrypt it), so slower usually than other approaches
• Current nonce-misuse resistant encryption modes
  • XCha-cha
    • Not nonce-misuse resistant
    • Large nonce (192 bits) allows random nonces
    • But, rngs may not be reliable on constrained devices
    • No non-libsodium implementations, that I can find
  • CAESER competitors
    • Probably good, but
    • No winner(s) announced, and won't be until later this year, at the earliest
  • AES
    • In AEAD-specification, limited to 96 bits of nonce, so can't use random nonce
    • Maybe skip AEAD interface and do it by hand, with a bigger nonce?
      • Ugh
  • Maybe specify, in XTT spec, that nonce is a SIV-style IV from the message?
    • Slow
    • Requires rolling our own, not good
    • We could use this model (see paper at https://eprint.iacr.org/2015/102.pdf) with some prf and regular AES-GCM to hack an SIV?
      • WARNING!!! NSA found attacks: https://mailarchive.ietf.org/arch/attach/cfrg/pdfL0pM_N.pdf

Remove expiry from server certificates

Cf. this issue in the xdaa-issuer repo for context.

The expiry field in the server certificate should be removed.

Update constants from Ed25519 to ECDSA

Remove root definitions that don't appear in on-the-wire structures

The spec currently defines a RootAlgType and ServerRootCertificate, neither of which are exchanged over-the-wire. While these may be useful for implementations to use for informative purposes, when storing root information, this spec needn't define them and should just let it be implementation-defined (or potentially a different spec).