[tor-dev] RFC of proposal draft for "Migration to ed25519 HS identity keys and privacy-preserving directory documents"

[Matthew Finkel]

On Fri, Sep 13, 2013 at 05:39:30PM +0300, George Kadianakis wrote:
> Here is another HS proposal draft.
>
> Inlining:
> 
> Filename: xxx-hs-id-keys-migration.txt
> Title: Migration to ed25519 HS identity keys and privacy-preserving directory documents
> Author: George Kadianakis
> Created: 13 September 2013
> Target: 0.2.5.x
> Status: Draft
> 
>                                          [More draft than Guinness.]
> 
> 0. Overview and motivation
> 
>   Proposal XXX introduces two new HS features:
>   a) Stronger HS identity keys.
>   b) New-style HS directory documents so that HS addresses are not
>      leaked to HSDirs.
> 
>   This document specifies how different Tor actors must act after
>   proposal XXX is implemented, so that the migration can proceed
>   smoothly.
> 

I assume XXX will be the number given to the combined prop for ecc keys
and preventing enumeration, yes?

>   We aim for the migration to be smooth both from the perspective of
>   Hidden Services (introduce grace period so that HS operators don't
>   wake up one day to find that their HS can't be accessed with that
>   address anymore) and from an implementation perspective (avoid
>   bloating the Tor protocol or introducing sensitive flag days).
> 
> 1. Migration strategy
> 
>   After proposal XXX is implemented:
>   a) The HS address format will change (called "new-style HS address"
>      in this document)
>   b) New HSDirs will be introduced (called "HSDirV3" in this document)
>   c) New-style HS descriptors will be introduced (called "HS V3
>      descriptors" in this document).
> 
>   The following sections investigate how these changes influence the
>   various Tor actors:
> 
> 1.1. From the PoV of Hidden Services:
> 
>   === XXX DISCUSSION XXX ===
> 
>   I see (at least) three migration strategies here. I'm not sure which
>   one is better so I'll write all of them and we can then discuss them
>   and pick one.
> 
>   a) After proposal XXX is implemented, Tor (configured as an HS) will
>      only publish HS V3 descriptors by default. There will be a torrc
>      parameter that the HS operator can use, that turns on publishing
>      of HS V2 descriptors for backwards compatibility with the old HS
>      address (the old identity key must be kept around).

I think I actually like this idea the best - from a usability
perspective. To ease the transition, Tor can have this option enabled by
default for some 0.2.5 alpha/beta releases. If you're comfortable that
this is working correctly, then you can flip the default to disabled for
the -rc's. This will allow relay and hidden service operators, who run the
latest version, to be early adoptors and begin to stress-test the new
system. Alternatively, perhaps a better plan is to leave the option as
enabled by default in 0.2.5 and disable it in 0.2.6. This latter option
provides operators with many months to transition users to their new
address without needing to know that they need to adjust their torrc.

In general, I think a PublishV2HiddenService is a better name than its
opposite, for b) below.

> 
>   b) After proposal XXX is implemented, Tor (configured as an HS) will
>      publish both V3 and V2 HS descriptors for each Hidden
>      Service. There will be a torrc parameter that turns off
>      publishing of V2 HS descriptors. This parameter will eventually
>      be switched off by default.
> 
>   c) After proposal XXX is implemented, Tor (configured as an HS) will
>      only publish V3 HS descriptors. The code that publishes V2
>      descriptors can be disabled or removed. HSes who want to publish
>      V2 descriptors (and keep the same address) will have to maintain
>      two copies of Tor -- one running the latest Tor version, and
>      another one running an older version that supports V2
>      descriptors.
> 
>   The engineer inside me tells me to go with c), but I feel that it
>   leaves all the burden to the HS operators.
> 

Indeed, although it is definitely the easiest, providing backward compat
is the better choice (unless the protocol is completely broken).

>   I haven't checked how much implementation effort doing a) or b)
>   would take us.
> 
> 1.2. From the PoV of the HS client:
> 
>   Tor clients can distinguish new-style HS addresses from old ones by
>   their length. Legacy addresses are 16 base32 characters, while new
>   ones are 56 (XXX) base32 characters.
> 
>   If Tor is asked to connect to a legacy address it SHOULD throw a
>   warning and advocate the use of new-style addresses (it should still
>   connect to the HS however). In the future, when old-style HS
>   addresses are close to depletion, we can introduce a torrc parameter
>   that blocks client connections to old-style HS addresses.

Depending on how this flag day is handled, maybe a consensus param will
be useful too?

> 
> 1.3. From the PoV of HS directories:
> 
>   Tor relays will advertise themselves as HSDirV3 servers using the
>   "hidden-service-dir" router descriptor line.
> 
>   For a while, relays will also continue being HSDirV2 servers. We will
>   specify a timeout period of X months (4?), after which relays will
>   stop being HSDirV2 servers by default (using the HidServDirectoryV2
>   torrc parameter).

The hidden-service-dir line currently looks like:

   "hidden-service-dir" *(SP VersionNum) NL

and if VersionNum is empty, it defaults to V2. When should this default
be changed? Is it better to change this immediately, or modify the
default as close to the flag day/release as possible?

> 
> 1.4. From the PoV of directory authorities:
> 
>   Authorities will continue voting for HSDirV2 servers. Eventually,
>   when all relays have upgraded and no one is claiming to be HSDirV2,
>   we can disable and remove the relevant code.

It may be better to chisel a day in stone for this. There will likely
be a loooong tail on the network completely migrating, and waiting for
the very last relay to upgrade could take years.

> 
> XXX Need to specify grace periods.
> XXX What did I forget?

Is there a similar high-profile migration that Tor or another project
went through that we can base this and/or improve upon this time around?

I think if we stick to KISS but "give them time" it will result in a happier
userbase.

It may also be a good idea to complete to implementation one component
at a time, such as HSDirs -> Dir Auths -> HS -> Clients. The obvious
disadvantage of this will be that testing is more difficult, until more
components are done but it ensures that if any node runs Master then
they won't start using the pieces before they're ready to be put
together.