Subject: [perpass] Another mail-related proposal

From: Jim Fenton <[email-masked]>
Date: Sat, 17 Aug 2013 13:43:55 -0700

When I read the purpose of this mailing list, an idea that had been in
the back of my brain came to mind, and I wonder if it fits with that
purpose. To Dave Crocker's point, I'm not sure whether you'd
characterize this as a privacy enhancement or confidentiality
enhancement, but here goes:

SMTP is biased in favor of delivering the message if at all possible.
While some MTAs use TLS to communicate, many do not, so TLS is
negotiated by mutual consent, but if that doesn't work out the message
is sent in the clear.  So if TLS breaks for some reason, people
frequently don't notice.

There might be times when I'm interested in sending a message that I'd
rather not be in the clear on the wire, and I'd rather that the message
bounce rather than be sent in the clear. How about an SMTP option that
allows a sender to specify whether the message transmission requires (1)
TLS and (2) that the receiving MTA also enforce this option. It could
also specify whether the recipient MTA is required to have a certificate
trusted (e.g., via trust chain) by the sending MTA, or whether any TLS
negotiation (e.g., self-signed cert) is OK.

This of course doesn't address a threat model that includes the MTAs
themselves, since they have the message in the clear.

So,

- Is this proposal the sort of thing this list is for?
- If so, any thoughts on the proposal?

-Jim

---

From: Paul Wouters <[email-masked]>
Date: Sat, 17 Aug 2013 17:25:58 -0400 (EDT)

> negotiation (e.g., self-signed cert) is OK.

I'd argue it the other way. If you publish a OPENPGPKEY/SMIMEKEY record,
then you ONLY want to receive encrypted email. The problem is trying to
prevent receiving it, as most email servers are message based and they
have to accept the full message before rejecting it, at which point the
cleartext has gone over the network and the NSA has a copy even if you
don't.

The postfix TLSA record fails hard for this reason - but that's the
transport security, not data security.

Paul

---

From: Jim Fenton <[email-masked]>
Date: Sat, 17 Aug 2013 23:05:51 -0700

> transport security, not data security.

I was, in fact, thinking about transport security, not data security. 
And I was thinking about being to set the preference on a
message-by-message basis. If I'm sending a message to my neighbors
announcing a block party, I would want the (existing) bias toward
message delivery. OTOH, if I'm sending a message to my accountant, I
might want to make sure it goes over a TLS-encrypted transport.

I'm having more trouble coming up with use cases where I'd want to
reject messages that don't use PGP or S/MIME. The originator of a
message is in a better position to decide whether it contains sensitive
information. And as the receiver you can't generally protect against the
message traversing the network in the clear -- SMTP is often more than
one hop and an earlier hop (or submission) could have been in the clear,
even if you did require TLS for the last hop.

-Jim

---

From: Randy Bush <[email-masked]>
Date: Sun, 18 Aug 2013 16:37:50 +0900

> reject messages that don't use PGP or S/MIME.

visualize a future world where e2e message privacy is the default.  in
that world, some parties could view an unencrypted message as an attack.

> The originator of a message is in a better position to decide whether
> it contains sensitive information. And as the receiver you can't
> generally protect against the message traversing the network in the
> clear -- SMTP is often more than one hop and an earlier hop (or
> submission) could have been in the clear, even if you did require TLS
> for the last hop.

i do what is in my power to do.  just because there might be a weakness
in the system n hops away does not mean i should indulge in weakness.

randy

---

From: Dan Schlitt <[email-masked]>
Date: Sun, 18 Aug 2013 10:01:59 -0400

I thought that I was long ago taught that encrypting only messages with 
"sensitive information" in them was bad security. The encrypted messages 
called attention to them and even if they could not be read were subject 
to traffic analysis.

/dan

-- 

Dan Schlitt
[email-masked]

On Sun, 18 Aug 2013, Randy Bush wrote:

> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

---

From: Jim Fenton <[email-masked]>
Date: Sun, 18 Aug 2013 09:33:53 -0700

> that world, some parties could view an unencrypted message as an attack.

I'm curious what sort of attack you're envisioning here: what are the
motives of the attacker, and what is the harm to the attacked party? I
have one idea -- a bit of a stretch IMO -- see below. But I wonder if
there are others.

> in the system n hops away does not mean i should indulge in weakness.

Here's a possible attack: someone sends you a message in the clear
falsely quoting you as conspiring criminally with them or some third
party. This might be part of a blackmail scheme, or simply from someone
who doesn't like you, analogous to the problems Brian Krebs has had with
some Russians
(http://www.onthemedia.org/2013/aug/02/russia-love-and-heroin/ ). The
attacker's intent would be to encourage some party doing passive
monitoring to subject you to additional (perhaps invasive) scrutiny.

But since email isn't necessarily directly from originating to recipient
MTA, your policy about requiring encrypted email doesn't necessarily
succeed. The attacker sends the message to the intermediate MTA in the
clear, the monitoring takes place, and your policy had no effect.

We're going down a very speculative path because we're nowhere near e2e
message privacy being the default. Personally, I'd rather focus on
improvements that we can make given the current situation, not some
possible future state of affairs.

-Jim

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 18 Aug 2013 17:42:05 +0100

Just on this particular attack:

On 08/18/2013 05:33 PM, Jim Fenton wrote:
> party. 

I think that's maybe on the boundaries of the scope here.
Even if the sender and recipient both think the message
is innocuous, the monitoring folks might not, so I'm not
sure that specific malicious content like that is what we
ought be worrying about in this context.

Put another way, that's an attack that's enabled by
monitoring, since if the monitoring wasn't likely or easy,
the attacker probably wouldn't try this method.

S.

---

From: Jim Fenton <[email-masked]>
Date: Sun, 18 Aug 2013 09:44:03 -0700

On 08/18/2013 07:01 AM, Dan Schlitt wrote:
>
> I thought that I was long ago taught that encrypting only messages
> with "sensitive information" in them was bad security. The encrypted
> messages called attention to them and even if they could not be read
> were subject to traffic analysis.
>

What I'm proposing is slightly different. We would still encrypt (at
transport level) all messages when that's possible, and the sensitivity
of the message would be visible only if the receiving MTA doesn't
support TLS or offer this extension. The sending MTA would first
STARTTLS, and if that fails would just QUIT, not giving a specific
indication about why it didn't send a message (although there would be
circumstantial evidence, of course).

Interesting observation.

-Jim

---

From: Yoav Nir <[email-masked]>
Date: Sun, 18 Aug 2013 18:49:45 +0000

> have one idea -- a bit of a stretch IMO -- see below. But I wonder if

Here's one. You and Randy are exchanging some emails. They're all encrypted, so listening in on your conversation is either impossible or prohibitively expensive. But the attacker finds some bug in your mail client, that makes it forget (or distrust) Randy's public key. Absent a public key, your mail client sends in the clear, and because of some BC code from the days when not all mail was encrypted, Randy's mail client displays the message. Because we all quote extensively, getting your side of the conversation is enough.

So the unencrypted message is not in itself an attack, but it is evidence of an attack. Does that mean it should be rejected? On the one hand, it's best to stop the conversation because it's not protected (and evidently is of some interest to someone). On the other hand, it makes no sense that the last message should be only available to an attacker. If some server in the middle is set up to drop all messages that are not encrypted (and the receiver has published a public key), this server may end up being before the point where the attacker is listening, foiling the attack. So I guess that could be an argument for dropping.

Yoav

---

From: Randy Bush <[email-masked]>
Date: Mon, 19 Aug 2013 09:08:22 +0900

> transport level) all messages when that's possible

and the nsa pwns the disk drives of the smtp relays.  e2e, please, in
addition to transport.  in 1984, all data and traffic should be
encrypted.

randy

---

From: Jim Fenton <[email-masked]>
Date: Mon, 19 Aug 2013 11:53:35 -0700

> So the unencrypted message is not in itself an attack, but it is evidence of an attack. Does that mean it should be rejected? On the one hand, it's best to stop the conversation because it's not pr…
That's an interesting use case, in part because something similar
happened to me the other day. I had sent a PGP-encrypted message to
someone who (not Randy of course) replied in the clear, quoting much of
my original message. The message wasn't all that sensitive, and my
correspondent was a new PGP user, but it seemed like a breach of etiquette.

In your example, the attack is only foiled if the attacker has not
monitored the link between the originator and the server in the middle,
which will not be the case if monitoring is indeed pervasive. Transport
encryption might help with this.

One of the difficulties I see is that the policy (perhaps not the best
word) for expressing a desire for all mail to be e2e encrypted is very
fine grained -- probably down to the individual email address.
Publishing and querying that information is likely to involve a whole
new set of of privacy concerns. Note, for example, that I'm not
suggesting that we publish that preference with WebFinger.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Mon, 19 Aug 2013 11:29:55 -0700

> addition to transport.  in 1984, all data and traffic should be
That goes to the question I had in my original message on this thread:
what is the threat model we are attempting to address? In the short term
at least, I consider transport-level encryption of email to be helpful,
because it raises the required attack complexity.

I also wonder if pwning the disk drives of the smtp relays is really a
passive attack. But I don't have the context of the discussions in
Berlin, so perhaps 'passive' is being interpreted broadly.

-Jim

---

From: Randy Bush <[email-masked]>
Date: Tue, 20 Aug 2013 09:38:44 +0900

> because it raises the required attack complexity.

i agree transport should be encrypted.  and, as someone has pointed out,
we should know when that negotiation is not successful and be able to
make some decisions.

smtp is hop by hop.  just because A encrypts to B, A has zero assurance
that B encrypts to C.  hence, e2e encryption is pretty much mandatory
against a purely passive attacker.

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 20 Aug 2013 09:43:05 +0900

> I had sent a PGP-encrypted message to someone who (not Randy of
> course) replied in the clear, quoting much of my original message.

[ i never make mistakes.  and pigs fly ]

one analog which worries me is muas which decide whether to encrypt
outbound depending on whether the inbound was encrypted.  if i do not
pay attention when responding, and i add confidential information in my
response.  if the inbound was not encrypted, my mua is not gonna encrypt
the reply by default.

randy

---

From: Jim Fenton <[email-masked]>
Date: Mon, 19 Aug 2013 22:24:01 -0700

> against a purely passive attacker.
...which goes back to the original thing I was suggesting: that A should
be able to signal to B that it should only relay the message (e.g., to
C) if the channel is also encrypted and that C also will observe the
restriction if it needs to relay the message further. Not as good as
end-to-end encryption, but an improvement nonetheless.

I believe the military folks might call this "Encrypt For Transmission
Only".

-Jim

---

From: Randy Bush <[email-masked]>
Date: Tue, 20 Aug 2013 14:27:36 +0900

> restriction if it needs to relay the message further.

and A trusts B and B's software and configuration why?  transport
encryption by default good.  e2e encryption by default gooder.  both
great.

randy

---

From: Jim Fenton <[email-masked]>
Date: Mon, 19 Aug 2013 23:26:21 -0700

> encryption by default good.  e2e encryption by default gooder.  both
A trusts B and B's software and configuration for the same reasons it's
willing to send a message to B at all.  Usually either because B acts on
behalf of A as an outgoing MTA, or because the recipient has designated
B to receive mail (directly or indirectly) for them.  It's not a huge
stretch from there for A to trust B to get the transport encryption
right too.

I agree on the good/gooder/great scale.  But sometimes the best we can
do is "good".

-Jim