On Thu, 24 Mar 2011 01:28:42 +0100
George Kadianakis <desnacked@xxxxxxxxx> wrote:
> Nick Mathewson <nickm@xxxxxxxxxxxxx> writes:
> > <SNIP: asn: Tidying up the thread a bit>
> > On Wed, Mar 23, 2011 at 1:36 PM, Robert Ransom <rransom.8774@xxxxxxxxx> wrote:
> >>
> >> The first step in the Great Tor Crypto Migration is to add new CREATE2
> >> and EXTEND2 RELAY cell types. They can be used with the existing
> >> circuit-extension handshake and link protocol initially, but will be
> >> extensible to support new ones.
> >>
> >> Further steps, all independent of each other:
> >>
> >> * Add 128-byte and 2048-byte RELAY cells and a circuit-configuration
> >> Âcell, initially to allow the client to change the cell size to be
> >> Âused on a circuit.
> >>
> >> * Refactor Tor's cryptographic primitive abstractions to accommodate
> >> Âpublic-key encryption primitives, public-key signature primitives,
> >> Âsymmetric authenticated encryption, symmetric block encryption, and
> >> Âhashes.
> >>
> >> * Implement one or more new link protocols that do not constrain a
> >> Ârelay's choice of identity key cryptosystem.
> >>
> >> Further mutually independent steps building on those above:
> >>
> >> * Modify the directory protocol and implementation to support relays
> >> Âwith multiple identity keys.
> >>
> >> * Implement a new circuit-extension handshake (the part that involves
> >> Ââonionskinsâ).
> >>
> >> * Implement a new circuit ciphersuite (the part that mangles cell data
> >> Âso that relay A can't see what data relay C sees).
> >
> > Hm. These steps all stretch pretty far beyond what's just described
> > in 3.2 of xxx-crypto-migration. I think they're probably more than we
> > can promise to design before summer, and possibly more than a typical
> > gsoc scope all put together.
> >
>
> This part:
> >> * Implement a new circuit-extension handshake (the part that involves
> >> Ââonionskinsâ).
> is in the xxx-crypto-migration, and it might be worthwhile to tackle
> during GSoC. I'm not sure about the BEAR/LIONESS operation (are you?),
> but if we are to design the new CREATE2 cells and we indeed don't
> like the current way of passing DH paramaters around, maybe we should
> find another protocol to do it.
Currently, we do not pass DH parameters around in the circuit-extension
protocol, just DH public keys. If we could pass new DH parameters in
that protocol, we wouldn't need new circuit-extension protocols quite
yet (although a new one would be a Good Thing anyway for performance
reasons).
> Of course, Robert's other ideas are holy and everything, but I think
> we should keep our goals humble so that we can produce an algorithmic
> implementation plan which will allow us to try to predict an
> implementation timeframe and see how many ideas we can fit into this
> GSoC project.
The list I gave above was purely to indicate some of the dependencies
between crypto migration tasks. I don't expect you to do all of them
for GSoC this summer; that list was intended to explain why you would
most likely not be able to migrate Tor to a new size or type of
identity key this summer.
> For example, things that definitely must be done are:
> - Implement CREATE2 cells aiming to:
> * Upgrade onion keys.
> * Upgrade DH group
> * Upgrade hash function.
> - Implement EXTEND2 cells aiming to:
> * Remove length limit, so as to be able to carry the new onion-skins and
> identity key fingerprints.
> Of course all these, while having in mind the upgradability of
> our design (ie. being versatile wrt the identity key)
The *entire point* of the EXTEND2 and CREATE2 cells must be to allow
future extension to new circuit and link protocols. We *will* want to
add new circuit and link protocols in the near future, and we shouldn't
need to add a new EXTEND17 or CREATE42 cell (and spend a cell type
number) for each new protocol.
> Then we can move on to:
> - Design a new onion-skin protocol.
> - Play with some of Robert's ideas above.
> - Touch the relay protocol.
> 'till the GSoC bell rings.
>
> What are your priorities on this project?
>
> >>> I'm also a little concerned about the interaction of 3.2 and 3.3
> >>> ("Relay crypto") : I'll be surprised if it turns out that we can
> >>> design a good circuit extend protocol without thinking about the
> >>> countours of a new relay protocol. Â(Not that you'd have to build both
> >>> at once, but we should think about them all as we design.)
> >>
> >> It's actually the other way around -- we need a new EXTEND cell before
> >> we can use a new link protocol. Â(Otherwise, we would have to build in
> >> a covert channel (i.e. a backdoor for people who want to block Tor by
> >> handshake) in the new link protocol to indicate client and server link
> >> protocol versions, and that really *really* sucks.)
> >
> > I'm talking about the stuff in 3.3: the relay protocol, where we
> > process cells. Link protocol stuff is 3.1.
> >
> > Also, I'm talking about *design order*, not *implementation order*:
> > The different parts of the Tor protocol are not sufficiently
> > orthogonal that we can do them independently. Thus, we need to get
> > most of the design changes sketched out before we can be reasonably
> > say that any part of the redesign does what the other parts need.
Circuit-extension handshake protocols and link protocols can be
designed independently of the rest of the protocol. Link protocols are
reasonably independent of the stuff sent over the link, and the
proposals/ideas/xxx-crypto-requirements.txt document should specify
*all* of the requirements for a new circuit-extension handshake
protocol to not break the rest of Tor's protocols. (We should still
dig through and annotate tor-spec.txt and rend-spec.txt with exactly
what properties each part requires of circuit handshake protocols, but
I'm quite sure I got all of those properties into
xxx-crypto-requirements.)
> >>> Maybe we should get a protocol sketch together this week if the app is
> >>> due April 8.
> >>
> >> Yes. ÂI have the EXTEND2 cell draft written; I bogged down on writing
> >> explanatory text (I thought I didn't have enough in the draft, but
> >> didn't know what to add).
> Sharing is caring!
See attached for a nearly-finished draft.
Robert Ransom
Filename: xxx-new-create-and-extend-cells.txt
Title: Adding new, extensible CREATE, EXTEND, and related cells
Author: Robert Ransom
Created: 2010-12-27
Status: Open
Overview and Motivation:
In Tor's current circuit protocol, every field, including the 'onion
skin', in the EXTEND relay cell has a fixed meaning and length.
This prevents us from extending the current EXTEND cell to support
IPv6 relays, efficient UDP-based link protocols, larger 'onion
keys', new circuit-extension handshake protocols, or larger
identity-key fingerprints. We will need to support all of these
extensions in the near future. This proposal specifies a
replacement EXTEND2 cell and related cells that provide more room
for future extension.
Design:
FIXME - allocate command ID numbers (non-RELAY commands for CREATE2 and CREATED2; RELAY commands for EXTEND2 and EXTENDED2)
The CREATE2 cell contains the following payload:
Handshake type length [1 byte]
Handshake type [variable]
Handshake data length [2 bytes]
Handshake data [variable]
The relay payload for an EXTEND2 relay cell contains the following
payload:
Link target specifier type length [1 byte]
Link target specifier type [variable]
Link target specifier length [2 bytes]
Link target specifier [variable]
Handshake type length [1 byte]
Handshake type [variable]
Handshake data length [2 bytes]
Handshake data [variable]
The CREATED2 cell and EXTENDED2 relay cell contain the following
payload:
Handshake data length [2 bytes]
Handshake data [variable]
All four cell types are padded to 512-byte cells.
When a relay X receives an EXTEND2 relay cell:
* X finds or opens a link to the relay Y using the link target
specifier in the EXTEND2 relay cell; if X fails to open a link, it
replies with a TRUNCATED relay cell. (FIXME: what do we do now?)
* X copies the handshake type and data into a CREATE2 cell and sends
it along the link to Y.
* If the handshake data is valid, Y replies by sending a CREATED2
cell along the link to X; otherwise, Y replies with a TRUNCATED
relay cell. (XXX: we currently use a DESTROY cell?)
* X copies the contents of the CREATED2 cell into an EXTENDED2 relay
cell and sends it along the circuit to the OP.
A link target specifier of type â??legacyâ?? contains the following
data:
Relay IP address (FIXME: byte order?) [4 bytes]
Relay OR port (FIXME: byte order?) [2 bytes]
Relay identity key SHA-1 digest [20 bytes]
These values are processed as section 5.1 of tor-spec.txt specifies
for the current EXTEND relay cell.
The first (client->relay) message in a handshake of type â??legacyâ??
contains the following data:
â??Onion skinâ?? (as in CREATE cell) [DH_LEN+KEY_LEN+PK_PAD_LEN bytes]
This value is generated and processed as sections 5.1 and 5.2 of
tor-spec.txt specify for the current CREATE cell.
The second (relay->client) message in a handshake of type â??legacyâ??
contains the following data:
Relay DH public key [DH_LEN bytes]
KH (see section 5.2 of tor-spec.txt) [HASH_LEN bytes]
These values are generated and processed as sections 5.1 and 5.2 of
tor-spec.txt specify for the current CREATED cell.
After successfully completing a handshake of type â??legacyâ??, the
client and relay use the current relay cryptography protocol.
Bugs:
This specification does not accommodate:
* circuit-extension handshakes requiring more than one round
No circuit-extension handshake should ever require more than one
round (i.e. more than one message from the client and one reply
from the relay). We can easily extend the protocol to handle
this, but we will never need to.
* circuit-extension handshakes in which either message cannot fit in
a single 512-byte cell along with the other required fields
This can be handled by specifying a dummy handshake type whose
data (sent from the client) consists of another handshake type and
the beginning of the data required by that handshake type, and
then using several (newly defined) HANDSHAKE_COMPLETION relay
cells sent in each direction to transport the remaining handshake
data.
The specification of a HANDSHAKE_COMPLETION relay cell and its
associated dummy handshake type can safely be postponed until we
develop a circuit-extension handshake protocol that would require
it.
* link target specifiers that cause EXTEND2 cells to exceed 512
bytes
This can be handled by specifying a LONG_COMMAND relay cell type
that can be used to transport a large â??virtual cellâ?? in multiple
512-byte cells.
The specification of a LONG_COMMAND relay cell can safely be
postponed until we develop a link target specifier, a RELAY_BEGIN2
relay cell and stream target specifier, or some other relay cell
type that would require it.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev