Subject: [Ehip] Fwd: Start discussion for draft-wchuang-grunion-01

From: Wei Chuang <[email-masked]>
Date: Fri, 18 Dec 2015 11:30:51 -0800

Resend to ehip since I butchered the ehip email address!

-Wei

---------- Forwarded message ----------
From: Wei Chuang <[email-masked]>
Date: Wed, Dec 16, 2015 at 5:42 PM
Subject: Start discussion for draft-wchuang-grunion-01
To: [email-masked], ietf-smtp <[email-masked]>

Hi all,

I would like to start discussion on draft-wchuang-grunion-01 (
https://tools.ietf.org/html/draft-wchuang-grunion-01) now that some of the
discussion of shutup@ is resolving.

Very quick summary of wchuang
- Use S/MIME, and use rewrap the messages to provide additional header
content privacy.
- Use intermediary proxy sender and recipients that hide the true sender
and recipient.
  - Proxies unwrap the message and forward
- Find the proxy sender and recipient through either X.509 certificate
extension
  or CMS extension.
- Differentiate privacy required by the proxies i.e. what message content
can been seen
by the proxy sender and recipients SMTP MTA.
Details of this can be found in draft-wchuang-grunion-01.

Some top level discussion points. First I wanted to contrast and show
similarities between ehip@ (draft-wchuang-grunion-01) from shutup@
(draft-josefsson-email-received-privacy-00).  Both proposals are attempting
to improve header privacy.  However josefsson is particularly interested in
Received headers, while wchuang is interested in hiding the sender and
recipient from the delivery path such that a MitM cannot find out
simultaneously who the true sender and true recipient are though the
adversary might find one or the other.  wchuang does mention that Received
headers are particularly difficult case to handle and mentions some
scenarios where it can be supported or suggests it might have to be
dropped.  wchuang does go into some different details than josefsson since
it specifies S/MIME.  This proposal makes some new requirements SMTP MTA to
support S/MIME processing to support unwrapping the proxied messages and
then forwarding the message.  As this forwarding process affects the mail
delivery path, wchuang also discusses supporting the NDR or bounced mail
case to return back along this altered path while maintaining privacy.

Another detail to discuss / understand is how the proxy selection occurs.
While at some level conceptually similar to TOR / onion routing there are
several differences to call out.  wchuang proposes that these proxies are
pre-determined statically and described in previously sent messages while
in TOR while the sender queries a directory server.  More specifically in
wchuang the sender finds from previously received messages the S/MIME
signature containing X.509 certificates with a new extension describing the
proxy adresses or similarly from the signature's CMS.  To prevent traffic
analysis, the proposal does suggest that the sender may choose from a list
of proxies, and that these proxies ought to have sufficient traffic volume
to make traffic analysis difficult.

That's a summary of what's being proposed.  I look forward to any
discussion.

-Wei