Hello,
There's been talk of moving to a wide block construct for cell crypto
(#5460), and for adding PQ Forward Secrecy to traffic (#17272). To
facilitate this, there needs to be a method for negotiating which
primitives a given relay supports.
To that end, here's the begining of a proposal (tentatively #260) that
adds a `CIPHERSUITES` cell to the version negotiation process which
allows relays to advertise the link cryptography primitives that they
are willing to accept.
TODOs/TBD:
* Should the new cell be variable length? Our development cycle and
how often we switch handshakes/link crypto tells me "No", the
existing "VERSIONS" cell format tells me "Yes".
* We need to revise prop. 249 to add a cell crypto method specifier to
CREATE2V/EXTEND.
* Proposal 249 does not cover changing RELAY_EARLY behavior, which
will potentially cause problems (Eg: Ring-LWE + ntor will require
between 5 to 9 fragments depending on the exact primitives).
* The actual hybrid construct is deliberately left unspecified.
* With runtime negotiation of primitives on a per-circuit basis, we
introduce the possibility of downgrade attacks. We do calculate
the SHA256 digest of VERSIONS/CERTS/AUTH_CHALLENGE cells (which
will become VERSIONS/CIPHERSUITES/CERTS/AUTH_CHALLENGE), so we could
do something like:
auth_input = verify | ID | B | Y | X | SLOG | PROTOID | "Server"
Where SLOG is the digest without too much difficulty...
The alternative to all of this would be something like including
handshake methods/supported link crypto in the descriptors, but that
seems silly.
Regards,
--
Yawning Angel
Filename: 260-cryptography-agility.txt
Title: Link Cryptography Agility
Created: 2015-11-15
Status: Draft
Extends: 249-large-create-cells.txt
1. Overview
This proposal aims to add per-circuit cryptographic agility, such that
the link handshake and cell layer encryption can be specified on au
per-circuit basis.
Once support for the negotiation mechanism in this proposal has been
deployed, it will be possible to introduce support for new circuit
handshake and/or cell encryption methods without the need for further
wire protocol changes.
2. Negotiation Process
The initator and responder MUST negotiate version 5 or higher to indicate
support for the CIPHERSUITES, CREATE2V and CREATED2V cells along with
fragmented EXTEND2 cells.
3. CIPHERSUITES cells.
Upon negotiating version 5 of the link protocol and sending a VERSIONS
cell, the responder sends a CIPHERSUITES cell befor sending the CERTS
cell to indicate which handshake methods, and which link encryption
primitives it supports.
(XXX: Should this be variable length? At the rate that we will change
handshake/cell crypto, I doubt space will ever be a concern, but
VERSIONS is variable length...)
struct ciphersuites_cell_body {
/* Number of supported handshake types */
u16 hlen;
/* Supported handshake types */
u16 handshake_types[hlen];
/* Number of supported cell crypto types */
u16 clen;
/* Supported cell crypto types */
u16 cell_crypto_types[clen];
/* Padding data to be ignored */
u8 ignored[];
};
The initiator then selects the "best" algorithms supported by the peer
as appropriate.
To prevent downgrade attacks, both parties MUST include the contents of
the CIPHERSUITES cell as part of the link handshake calculations, for
example by including the SLOG (AUTHENTICATE cell) SHA256 hash in the
ntor "auth_input" field.
XXX: It occurs to me that we should include a 2 byte cell crypto specifier
in the CREATE2V/fragmented EXTEND2 cells.
4. Cell Crypto Types
The following cell crypto types are defined and reserved:
0x0000 - CTR-AES128 + SHA1 -- the original Tor cell crypto
0x0001 - reserved (AEZ?)
Attachment:
pgpzKEXqd9b1m.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev