Re: API (was: "FORWARD" module)

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

On Wed, 2002-03-27 at 11:42, George Danezis wrote:
> On 27 Mar 2002, Nick Mathewson wrote:
 [...]
> >         (BIG QUESTION)
> > ...but I'm still worried about the problem that got us onto this track:
> > How can SURBs work with fragments?  If anybody can explain this, I'd be
> > happy.  (For that matter, how do you specify your email address in a
> > SURB?)
> 
> The original idea was:
> 
> The createtor of the SURB ties the SURB to a particular module that it is 
> going to be handled by when it is received. Therefore it is possible that 
> the type is set to be "FRAGMENT" and is treated as such by the receipient. 
> Of course when the fragments are reconstructed together the result could 
> be pipped to another module or application.
> 
> The point is that we should not allow the sender to specify that the 
> message should be handled by the SMTP module of the receiver (or any 
> other module with visible side effects). If it is allowed a trivial 
> attack to deanonymise them would be to send a message asking to send 
> an email to the attacker. 

Would the following solution work:

If we _don't_ consider fragment reconstruction, and we place the
application type at the head of the final block[*]

  E_M1(MH1) | E_K1(E_M2(MH2) | E_K2( E_M3(MH3) | E_K3(SMTP-TYPE, To: Bob )))

 (Where Kn == H(MSn|"Secrecy_Mode"))

Thus, when Alice appends her message (MSG), M3 will eventually receive:

  SMTP-TYPE, To: Bob E_K3(E_K2(E_K1(MSG))))
  (With each of the keystreams displaced by an appropriate number of bytes).

And Bob can read his message, but Alice can't append anything to the reply
block that would change the handling of the final message.

With fragmented messages, the situation is harder.  One possibility is
to make some headers with the payload "FIRST-FRAGMENT (SMTP-TYPE To:
Bob)" and others with the payload "OTHER-FRAGMENT."  Of course, such a
system wouldn't have a good way for the sender to mark the number of
fragments.  Then again, it's unclear that I'd want to give other people
the ability to send me super-large emails without their first telling me
about how long they had in mind.  Thus, if Bob wants to receive mail up
to about 180K, he might give out reply blocks in triads of the form:
      FIRST-FRAGMENT [1/3] (SMTP-TYPE To: Bob)
      OTHER-FRAGMENT [2]
      OTHER-FRAGMENT [3].

Does this look okay?  Any other solutions?  Any solutions to the problem
of Bob _wanting_ to receive unbounded email?

[*] I suggest that _application_ types get moved into the head of the
block for the reason that payloads nest: one can have a fragmented,
gzipped, smtp message.  Once we specify a few applications, I'm fairly 
sure it will converge on a design like this.


>>         (LITTLE QUESTION)
>> [BTW, does anybody mind the potential for homophonic confusion between
>> SURBs and Serbian people?  If so, we should pick a new name or
>> abbreviation ASAP.]
>> 
>
>The proper term to refer to the serbian people is "serbian". The term 
>"serb" has been used extensivly in the UK media during the latest 
>interventions to dehumanise serbian people and their cultural attache here 
>was not impressed by it at all. I do not think that there is a phonetic 
>conflict here.

[FYI, the USian media does the same.]

Well, if people are fine with the name, I suppose I am too. My worry was
more or less what you mention: that a homonym for an offensive term for
a group of people could itself be offensive.

The only alternatives I could come up with were "SRB" for "Single-use
Reply Block"; or  "OTRB" for "One-time Reply Block" (potential confusion
with meaning of OT in OTP).  If this worries nobody else, I'll drop it;
otherwise I'll suggest a trisyllabic 'SRB' to abbreviate the
hexasyllabic original.

Yrs,
-- 
Nick