xaptum / xtt-spec Goto Github PK
View Code? Open in Web Editor NEWWorking draft for the XTT RFC
Working draft for the XTT RFC
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:
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).
Cf. this issue in the xdaa-issuer repo for context.
The expiry
field in the server certificate should be removed.
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.
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:
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:
IV = prf<Key>(nonce | addl-data | plaintext)
https://eprint.iacr.org/2015/102.pdf
) with some prf and regular AES-GCM to hack an SIV?
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.