Re: Comments on latest draft

[Nick Mathewson <nickm@alum.mit.edu>]

Thank you, George, for your prompt comments.

By the way, other people should check out this document as well. I'm
probably the _least_ sophisticated cryptography or protocols person in
this bunch, and it would be cool if others could find what I've
doubtlessly missed.

(Lastly, what I snip below, I agree with.)

On Tue, 2002-03-26 at 07:47, George Danezis wrote:
 [...]
> Note that we do not define a mixing method in the standard. I am not sure 
> how prudent that is. Maybe we should require a minimum level of traffic 
> and mixing from each node.

Perhaps the PK block should advertise the alleged mixing capabilities of
the mixes.
 
  [...]
> >    f. When last we met, we suggested that "type" be a string, and not be
> > in the header.  Now it's 2 bytes in the header.  Any reason why?
> >     
> 
> This is a basic multiplexing mechanism to facilitate the job of the server 
> logic that redirects the packet to the appropriate module for processing. 
> You can think of it like the protocol type in IP headers or the Port type 
> of TCP/UDP. The message body can then contain any additional configuration 
> information specific to the module.

I'm not yet persuaded that this either helps or hurts server logic very
much.

> > 5. BIG ISSUE: It looks like multi-use reply blocks (MURBs) are back in. 
> > The problem is: I still don't think they work.
> >    a. If I'm reading the spec right, we use the same IV for every pass
> > through the system.  This results in multiple uses of counter-mode with
> > the same IV: a trivially exploitable flaw.
> >    b. We were trying last time (it seems) to find a good way to build
> > MURBs without adding a separate "type-1 remailer" mode to our system.  I
> > think this should still be a goal: traffic of this kind will be
> > colossally vulnerable to traffic analysis by hostile nodes if it is so
> > readily distinguishable from the rest of the traffic through the system.
> >       At the very least, we should acknowledge as a goal the desire to
> > take this feature out of the system.
> >    c. Why have a separate field in the MH for reuse level?  Why not just
> > introduce another message type for type-1 remailer reply, if we're going
> > to support both modes?  This way, we could specify another encryption
> > mode for these messages, and avoid (a) above.
> 
> I have been thinking of MURBs a lot. Basically they do not work even under 
> the most weak threat model assumptions. I agree that counter mode does not 
> make things better but after some though I have convinced myself that it 
> does not make things worse either. Intermediate nodes are always able to 
> see their position in the chain (which is always the same), they can link 
> messages together (they must have the same header). They can also tag 
> messages and follow them through the mix network.

But with Counter mode, MURBs run into a problem they would not otherwise
encounter.  Suppose Alice sends messages MSG1 and MSG2 to Bob via a MURB
routing through M1, M2, M3, and M4.  Because she does not care to hide
her own identity, she sends MSG1 and MSG2 in the clear.  Also, Mallory
has compromised M4.

If we're using another cipher mode, Mallory sees
C1=E_M3(E_M2(E_M1(MSG1))) and C2=E_M3(E_M2(E_M1(MSG2))).  Though he
would know that both messages were sent with the same reply block, and
both were sent to Bob, he couldn't deduce much about the contents of
MSG1 or MSG2.

But suppose we're using counter mode for MURBs.  This time, we'll have
C1=MSG1 XOR KeyStream, and C2=Msg2 XOR KeyStream.  This of course yields
C1 XOR C2 = MSG1 XOR MSG2, and so Malory can learn MSG1 XOR MSG2.  From
this, learning the original _contents_ of the secret messages sent to
Bob is trivial.

> I increasingly think they are a truly bad idea, because they seem so 
> convenient. People are going to use them instead of building proper 
> systems, offering strong anonymity.

I agree that MURBs, in the sense of type-1 remailer reply blocks, are
bad for precisely the reason you describe.  Naturally, I believe that we
should continue to contemplate ways to make good substitutes, or to make
them good.  

 [...]
> >       - Political #2: "He who would make his own liberty secure, must
> > guard even his enemy from oppression; for if he violates this duty, he
> > establishes a precedent that will reach to himself." (Thomas Paine)
> >       - Any other thoughts?
> 
> I quite like Political #2. Political #1 has the problem that it also  
> contains:
  [...]

I like political #2 as well, though we can hold off for a while. 
Doubtlessly this is not the best quote about freedom or privacy that
anybody can find with Google, Bartlett's, or some comparable resource.
:)

 [...]
> > 9. Administrative issues: 
> >    a. The capabilities block needs to be better specified. I'd recommend
> > a list of supported message types, and leave it at that.
> >    b. Why <LFCR>?  Is that just a notation for "platform-appropriate
> > newline," or do you mean something else?
> >    c. There should be a standard way IMO to query a server's public key
> > from the server.
> 
> Who want to rework these?

I'd be able to look at improving the document tonight, but no sooner. 
By "these" did you mean (9), or all the issues in the document?

Yours,
-- 
Nick