[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: tor-spec comments
- To: or-dev@freehaven.net
- Subject: Re: tor-spec comments
- From: Nick Mathewson <nickm@alum.mit.edu>
- Date: Tue, 02 Sep 2003 13:24:16 -0400
- Delivered-to: archiver@seul.org
- Delivered-to: or-dev-outgoing@seul.org
- Delivered-to: or-dev@seul.org
- Delivery-date: Tue, 02 Sep 2003 13:26:04 -0400
- In-reply-to: <20030830021334.O7514@moria.mit.edu>
- References: <E19spWy-0007Ee-00@xanthine.gratuitous.org> <20030830021334.O7514@moria.mit.edu>
- Reply-to: or-dev@freehaven.net
- Sender: owner-or-dev@freehaven.net
On Sat, 2003-08-30 at 02:13, Roger Dingledine wrote:
[...]
> On Fri, Aug 29, 2003 at 04:07:36PM -0400, Joel N. Weber II wrote:
> > 1) I really don't understand what would be wrong with using TLS as the
> > basis for a secure channel, with some sort of multiplexing layer on
> > top of that.
> >
> > I'm thinking of a system in which you have a secure channel between
> > each pair of connected onion routers, and then the client builds a
> > stack of nested TLS sessions for each hop it wants to route through.
[...]
> Paul, Nick, want to try answering this more thoroughly? It needs to
> go in the FAQ, because people keep asking it (or if we can't answer it
> sufficiently, we should start looking at switching).
IMO using TLS for links is reasonable, but I question whether it's a
good idea to do it for circuits and streams. Trying to keep all "cells"
looking alike as they cross the wire would require some weird padding,
and I don't think TLS-over-TLS is up to the task because of padding and
record length issues. (IOW, if you're tunnelling TLS-over-TLS-over-TLS,
it's hard to keep all the cells/records to a constant length.)
I don't think that layering SSH2 on itself is a good idea from this
perpective either. The structure of an ssh2 packet is (according to
draft-ietf-secsh-transport-16.txt):
uint32 packet_length
byte padding_length
byte[n1] payload; n1 = packet_length - padding_length - 1
byte[n2] random padding; n2 = padding_length
byte[m] mac (message authentication code); m = mac_length
If we use SSH2-over-SSH2-over-SSH2, the payload of each SSH2 record
would need to contain another SSH2 record. There may be some way to
re-pad this embedded record before retransmitting it to the next OR so
that the next OR can't tell its place along the chain, but I don't see a
clever way to do so.
Thus, I think that if we believe that all cells should look alike to an
eavesdropper, and if we believe that all relayed RELAY cells should look
alike to an OR, then using nested TLS or nested SSH is not an easy way
to do it.
(Once again, this is only about using nested TLS/SSH for a circuit
protocol. Using TLS or something like it for a link protocol seems like
a lovely idea.)
--
Nick