[messaging] Panoramix decryption mixnet messaging spec and design documents

[dawuud]

replying inline...

> > End to end reliability can only be achieved using an Automatic Repeat
> > reQuest protocol scheme which resides in the client. If you do not
> > require reliability then the client becomes a lot simpler in it's
> > design and implementation.
> > 
> > Take a moment to consider what might happen if we tried to make the
> > mix network reliable without involving the client. In this case we
> > could implement some sort of store and forward mechanism in each
> > component mix... but ultimately if there is a mix outage this cannot
> > guarantee reliable transmission of messages.
> > 
> > We have intentionally designed the client to be smart and the network
> > components to be relatively dumb in accordance with the End to End
> > Principle.
> 
> Thanks, that's good to know. So does this mean the mixes and providers
> aren't involved in reliability at all - it's all client to client?

Our Stop and Wait ARQ scheme terminates on the destination Provider.
If it was client to client then both clients would have to be online
at the same time.

> But I think the mix layer has been adapted to the needs of the
> reliability layer to some extent by adding SURBs, right? And in a

No. The mix net gives zero fucks about reliability.
Fundamentally mixnets are an unreliable packet switching network.

> previous message you mentioned "source quench" from mixes to providers.

No. I didn't. Trevor mentioned it. This is an implementation detail
and is more related to flow control. It's definitely not part of any
ARQ protocol scheme.

> So I'm trying to understand which bits of the reliability design are
> provided by which components.

The source client and the destination provider are involved. It's an ARQ protocol.
I suggest you read up on ARQ protocol schemes. Wikipedia has some decent articles
on the subject. There's a vast amount of literature on this subject which may
help clear up your misunderstanding of what reliability means in the context
of an unreliable packet switching network.

> Maybe I just need to read the specs, but I was hoping you could give me
> an overview.

Yes perhaps reading the specs would be helpful. I am trying to answer your
questions here but I don't know you and I don't know your technical background
so it's difficult for me to determine how much I need to explain and how much
is obvious to you.

> >> Sending a notification as
> >> soon as a message arrives at the provider exposes more metadata to a
> >> global passive adversary than holding onto the message until the user
> >> polls for it - but on the other hand users of some applications may
> > 
> > That is only a correct statement if there is no decoy traffic to the
> > client whereas we expect to specify decoy traffic in future revisions
> > of our design. If you pay close attention to the Loopix paper, you'll
> > see that it specifies several types of decoy traffic, some of which
> > terminate on the client. These are important aspects of the Loopix
> > design that should not be ignored.
> 
> Don't worry, I didn't ignore them. :-) I've read the paper but I'm
> interested in what design choices will be implemented in Panoramix.

I am not worried about anything.

> In the case I was talking about above, where the client's online but
> asleep, a network observer may be able to distinguish a decoy message
> that's silently consumed by the client from a real message that turns on
> the screen, causing other applications to wake up and hit the network.

That's stupid, we wouldn't do that. It totally defeats the purpose of
decoy traffic.  Do you see why I have to write this? We cannot have a
decoy traffic design which allows a passive network adversary to
distinguish between legit and decoy message.

Furthermore I really do not care about desiging user interfaces or
cell phone applications. Zero fucks given. I mean... I can work and
collaborate with others who are concerned with that but I'm not going
to do the design work for that stuff. Cognitive diversity is a huge
factor...  and I'm just not the right person to engage in conversation
on this particular topic but there are amazingly smart people that I'm
sure would be more than happy to chat with you about that... but I
would question if that belongs on this mailing list.

> That's just one scenario and I don't want to get hung up on it, but

OK good. Then let's just not talk about that anymore.

> there are other considerations for mobile clients: decoy messages
> consume bandwidth and power, and a mobile app may not be able to wake up
> to send decoy messages on an arbitrary schedule. So my broader question
> is how much control an application using Panoramix, or even an
> individual client, will have over the decoy traffic parameters, and how
> those choices will affect anonymity.

By the way the name Panoramix refers to a much bigger project than this
decryption mixnet. So far we've named our implementation Katzenpost
because the committee hasn't told us to rename it yet.

This is really a question about the Loopix paper if you are asking about
the anonymity set size on mixes versus decoy traffic versus legit traffic.

On the other hand your question is also essentially a trick question
because you are assuming that the application's interface with the
mixnet includes control over decoy traffic whereas from my perspective
the mixnet is designed to support specific applications and therefore
the appropriate decoy traffic will have already been selected.

Or said another way: "Do you really think an e-mail client should let
the user select the frequency of decoy messages sent over the mixnet?"

> > That having been said, I can tell you that the current rough draft
> > client I have written has a SMTP submition proxy and a POP3 receive
> > proxy that are meant to run locally on the client's endpoint
> > device. This flexible design blurs the definition of "client".
> > 
> > This mixnet client as written performs periodic polling of the
> > Providers for which the user has an account. I'm willing to change the
> > implementation of the client if our Android developer wishes it,
> > however the primary goal of using SMTP and POP3 as interaction
> > mechanisms was to avoid heavily modifying the k9mail client to perform
> > lots of crypto operations. This was mainly done because we do not wish
> > to write our mixnet crypto libraries in multiple languages at this
> > time. Our code base is all in golang whereas k9mail is written in
> > Java.
> > 
> > Of course this also means that our current "client" should work
> > with well with all e-mail clients that use SMTP and POP3.
> 
> It's great to know you're working with k9mail - I'm excited to try out
> the client, and then I can start pestering you with specific questions
> rather than vague ones. ;-)

No. Please do not ask me questions about k9mail or anything related to user interface.
Go and read our specs and feel free to ask me questions about our design, not he user interface.


Sincerely,
David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20170921/72ca61c8/attachment.sig>