Re: [pkix] Identified Work Items and Discussion Summary (was: possible new pkix and/or smime work)

[Tom Ritter <[e-mail]>]

On 1 April 2016 at 12:47, Wei Chuang <[e-mail]> wrote:
> There's also an experimental RFC7508 "Securing Header Fields with S/MIME"
> plus RFC5751 mentions using message/rfc822 though that is not completely
> specified.  One issue likely common with these approaches is keeping private
> the sender and recipient(s).  I've pitched the idea of doing some form of
> onion routing to mitigate that.  Hopefully these are things folks would be
> interested in pursuing.

I'm super interested in that.

I've been interested and worked casually on mix networks for a bit,
for strong anonymity. But there are lots of problems there, including
reliability (and throughput) of nodes, abuse, and of course the 'going
dark on spam' problem . Lately I've been thinking about something
weaker and potentially more deployable.

Model it as four parties at play: Sender, Receiver, Sender Provider,
Receiver Provider. Right now each party sees everything - goal is to
reduce that.

One idea I've had is that each provider can publish a
[e-mail] address.  You encrypt a message to
[e-mail] specifying [e-mail] as the recipient with
the body additionally encrypted (or not) to Alice. Google decrypts and
then forwards to Alice. This makes the Recipient private from the
Sender Provider, and doesn't impact any sort of incoming spam
controls.  (It does impact outgoing spam controls to a certain
degree.)

Another idea is that the sending provider can strip all identifying
information from the message as it passes through them. The
information is contained inside the encrypted envelope to the final
recipient. Sending provider will still know who's sending the message
(SMTP authentication) - but the Receiving Provider doesn't learn the
Sender.  You've got lots of concerns about impersonation here, but I
think we could device a cryptographic protocol that gives the Sending
Provider assurance the Sender isn't trying to masquerade as someone
else. (The simplest one would just have the Sending Provider encrypt
the Sender to the Recipient.)

-tom