mirror of
https://github.com/torproject/torspec.git
synced 2024-12-12 04:35:37 +00:00
71 lines
2.6 KiB
Plaintext
71 lines
2.6 KiB
Plaintext
Filename: 231-migrate-authority-rsa1024-ids.txt
|
|
Title: Migrating authority RSA1024 identity keys
|
|
Authors: Nick Mathewson
|
|
Created: 8 April 2014
|
|
Target: 0.2.?
|
|
Status: Obsolete
|
|
|
|
Note: Obsoleted by Ed25519 ID keys; superseded by 240 and 256.
|
|
|
|
1. Intro and motivation
|
|
|
|
We'd like for RSA1024 identity keys to die out entirely. But we
|
|
may need to migrate authority identity keys before that happens.
|
|
|
|
This is especially important because proposal 220 ("Migrate
|
|
server identity keys to Ed25519") is not yet implemented, and so
|
|
server identity keys are not kept offline. So when an OpenSSL
|
|
bug like CVE-2014-0160 makes memory-reading attacks a threat to
|
|
identity keys, we need a way for authorities to migrate ASAP.
|
|
|
|
Migrating authority ID keys is a trickier problem than migrating
|
|
router ID keys, since the authority RSA1024 keys are hardwired in the
|
|
source. We use them to authenticate encrypted OR connections to
|
|
authorities that we use to publish and retrieve directory
|
|
information.
|
|
|
|
This proposal does not cover migrating RSA1024 OR identity keys for
|
|
other nodes; for that, see proposal 230.
|
|
|
|
2. Design
|
|
|
|
When an authority is using a new RSA1024 key, it retains the old one
|
|
in a "legacy_link_id_key" file. It uses this key to perform link
|
|
protocol handshakes at its old address:port, and it uses the new key
|
|
to perform link protocol handshakes at a new address:port.
|
|
|
|
This should be sufficient for all clients that expect the old
|
|
address:port:fingerprint to work, while allowing new clients to use
|
|
the correct address:port:fingerprint.
|
|
|
|
Authorities will sign their own router descriptors with their new
|
|
identity key, and won't advertise the old port or fingerprint at all
|
|
in their descriptors. This shouldn't break anything, so far as I
|
|
know.
|
|
|
|
3. Implementation
|
|
|
|
We'll have a new flag on an ORPort: "LegacyIDKey". It implies
|
|
NoAdvertise. If it is present, we use our LegacyIDKey for that
|
|
ORPort and that ORPort, for all of:
|
|
|
|
* The TLS certificate chains used in the v1 and v2 link protocol
|
|
handshake.
|
|
|
|
* The certificate chains and declared identity in the v3 link
|
|
handshake.
|
|
|
|
* Accepting ntor cells.
|
|
|
|
4. Open questions
|
|
|
|
On ticket #11448, Robert Ransom suggests that authorities may need to
|
|
publish extra server descriptors for themselves, signed with the old
|
|
identity key too. We should investigate whether clients will
|
|
misbehave if they can't find such descriptors.
|
|
|
|
If that's the case, authorities should generate these descriptors,
|
|
but not include them in votes or the consensus; or if they are
|
|
included, don't assign them flags that will get them used.
|
|
|