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

[George Kadianakis <desnacked@xxxxxxxxxx>]

Here is another HS proposal draft.

This one specifies how to migrate from the current HS protocol to the
one specified in proposals "Migrate HS identity keys to Ed25519" and
"Stop HS address enumeration by HSDirs":
https://lists.torproject.org/pipermail/tor-dev/2013-August/005279.html
https://lists.torproject.org/pipermail/tor-dev/2013-August/005280.html
(I will soon write a proposal that merges these two proposals into one)

This proposal is in serious need for comments. Specifically, see
section "1.1. From the PoV of Hidden Services" which I left entirely
unspecified. There are also probably multiple migration concerns which
I have forgotten or completely ignored.

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.

  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).

  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.

  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.

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).

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.

XXX Need to specify grace periods.
XXX What did I forget?
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev