Subject: [perpass] Avoiding abuse related to large scale encrypted email

From: Douglas Otis <[email-masked]>
Date: Thu, 3 Oct 2013 18:58:47 -0700

Dear Perpass WG,

Several have expressed valid concerns regarding abuse of encrypted email.  While CAs may not be trustworthy, it seems DANE offers a workable and reasonably transparent  alternative to protect against undetected tampering.  In addition, DANE reduces incremental costs associated with certificates which should prove beneficial for email use.

That said, proprietary schemes are available permitting multiple decoding keys derived from conveyed indexes.  The derived keys are assigned to outbound message scanners used by enterprises to ensure governmental data compliance requirements while also ensuring the integrity of the entire path traversed.  If there is interest, I could prevail on my employer to disclose IPR terms and details.

Secondly, while web based TLS exchanges normally ignore client certificates, this would not be desirable for StartTLS related to open email exchanges.  Currently, only source IP addresses are effectively used to defend SMTP servers.  DKIM does not offer a suitable replacement because it fails to capture who initiated the exchange, and to whom it was being sent.  In other words, DKIM lacks essential elements needed to properly identify those accountable for email abuse.

IPv6 will significantly challenge the use of source IP addresses.  While the number of legitimate addresses may represent a reasonable number, most of email is sourced from compromised systems likely using privacy extensions.  Just a bit map tracking whether a /64 prefix is active requires 5,650 Terra-bytes to cover just the announced /64 prefix space.  At any point in time, a bit more than 100 million registered domains are active that collapses down to subdomains below the registrar.  This relatively small number is fairly manageable compared against IP addresses, even when attempting to just white-list new MTAs.

A domain based approach may seem fairly disruptive, but even the best content scanners fail to provide full detections while demanding significant resources. Content based acceptance is not cost effective as the first stage in a vetting process.  One hundred thousand domains control 90% of the Internet traffic. The top 150 domains control 50%, and the top 2,500 domains control 75%. 

Secure SMTP using DNS-Based Authentication of Named Entities (DANE) TLSA records and SMTP security via opportunistic DANE TLS offer interesting starting points.  For this to work well, a more disruptive approach is required where sending domains should be encouraged to use their own certificates.  The initial availability of TSLA RRs should not miss the opportunity to use this to signal a new paradigm of expectations.

Regards.
Douglas Otis

---

From: Paul Wouters <[email-masked]>
Date: Mon, 7 Oct 2013 10:33:40 -0400 (EDT)

On Thu, 3 Oct 2013, Douglas Otis wrote:

> Several have expressed valid concerns regarding abuse of encrypted email.

One can always request encrypted email is signed. Than an abuser's key
can simply be blacklisted. Or all encrypted but not signed email can be
refused or disgarded. Encryption and key verification in DNS is actually
a really good anti-spammer tool.

> That said, proprietary schemes are available permitting multiple decoding keys derived from conveyed indexes.  The derived keys are
> assigned to outbound message scanners used by enterprises to ensure governmental data compliance requirements while also ensuring the
> integrity of the entire path traversed.  If there is interest, I could prevail on my employer to disclose IPR terms and details.

Generaly, I think people are only interested in hearing unencumbered
ideas. So unless your employer has license terms that are unrestricted,
I at least do not wish to hear it.

> Secondly, while web based TLS exchanges normally ignore client certificates, this would not be desirable for StartTLS related to open
> email exchanges.  Currently, only source IP addresses are effectively used to defend SMTP servers.

See above. If that is a concern, simply block encrypted but unsigned
email. Or only allow signed email if the public key is available in DNS.

> IPv6 will significantly challenge the use of source IP addresses.

Someone should tell Paul Vixie that, his ipv6 reverse check is
preventing me from emailing him on various occasions when my mail
client happens to get some v6 address :P

> Secure SMTP using DNS-Based Authentication of Named Entities (DANE) TLSA records and SMTP security via opportunistic DANE TLS offer
> interesting starting points.  For this to work well, a more disruptive approach is required where sending domains should be encouraged
> to use their own certificates.  The initial availability of TSLA RRs should not miss the opportunity to use this to signal a new
> paradigm of expectations.

I am not sure what you are saying here?

encryption is unrelated to authentication or authorization. spam and
verifiable email origin are unrelated to encrypted the content (and/or
meta data) of email. It just happens that we used to use the content
and/or metadata to mark bogus email as spam. Clearly that has to change
if we are successful at hiding those properties from passive attackers
as well as anti-spam technologies.

Paul

---

From: Richard Barnes <[email-masked]>
Date: Mon, 7 Oct 2013 15:09:09 -0400

> a really good anti-spammer tool.

Note that this would require Encrypt-then-Sign or
Sign-then-Encrypt-then-Sign, either of which has some security implications.
<http://tools.ietf.org/html/rfc5751#section-3.6>

--Richard

>
>
>  That said, proprietary schemes are available permitting multiple decoding
>> keys derived from conveyed indexes.  The derived keys are
>> assigned to outbound message scanners used by enterprises to
>> ensure governmental data compliance requirements while also ensuring the
>> integrity of the entire path traversed.  If there is interest, I could
>> prevail on my employer to disclose IPR terms and details.
>>
>
>  Secondly, while web based TLS exchanges normally ignore client
>> certificates, this would not be desirable for StartTLS related to open
>  Secure SMTP using DNS-Based Authentication of Named Entities (DANE) TLSA
>> records and SMTP security via opportunistic DANE TLS offer
>> interesting starting points.  For this to work well, a more disruptive
>> approach is required where sending domains should be encouraged
>> to use their own certificates.  The initial availability of TSLA RRs
>> should not miss the opportunity to use this to signal a new
> ______________________________**_________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/perpass<https://www.ietf.org/mailman/listinfo/perpass>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 7 Oct 2013 16:07:02 -0400

> <http://tools.ietf.org/html/rfc5751#section-3.6>

Please be specific.

There is no consensus on the order of operations and never will be because
there are security considerations of doing it either way.

There are more options than S(E(m,k1),k2) or E(S(m,k2),k1) as well.

Encryption takes place under a session key and that session key can be used
to encrypt the hash or encrypt the message.

So be precise, it is really important here. One of the things that holds
the field back is that a lot of the time repetition of lore substitutes for
thinking.

The scheme I am currently working with has a policy layer so at the same
time the email recipient publishes their key they tell people how to use it
to send them mail.

This allows for constraints such as:

1) Always try to send me encrypted mail.

2) Only send encrypted mail on prior permission.

3) Encrypt data to my personal key

4) Encrypt data to the organization's key.

5) Encrypt data to my personal key, sign it and then super encrypt under
the enterprise key.

Pre-PRISM we used to argue about choice A or choice B.

What Bruce-who-has-seen-the-docs tells me is that when the NSA has that
choice their answer is always do both.

And we have to do the same if we are going to win this.

-- 
Website: http://hallambaker.com/

---

From: Richard Barnes <[email-masked]>
Date: Mon, 7 Oct 2013 16:45:46 -0400

I'm not proposing anything new here.  My point was simply that if
anti-abuse requires the sender's key is on the outside, then it rules out
some schemes.  Namely any scheme where the signature only exists within an
encrypted segment (e.g., your E(S(m,k2),k1)).  This limitation could be
considered an undesirable side-effect of Paul's proposal to use the
signature for anti-abuse.

--Richard

On Mon, Oct 7, 2013 at 4:07 PM, Phillip Hallam-Baker <[email-masked]>wrote:

> Encryption takes place under a session key and that session key can be
> used to encrypt the hash or encrypt the message.
>

---

From: Trevor Perrin <[email-masked]>
Date: Mon, 7 Oct 2013 13:51:18 -0700

On Mon, Oct 7, 2013 at 7:33 AM, Paul Wouters <[email-masked]> wrote:

> One can always request encrypted email is signed.

FWIW,

Pond's use of group signatures (with traceability) for anti-abuse is a very
clever idea along these lines, and avoids some of the disadvantages (e.g.
loss of deniability and anonymity) of traditional public-key signatures.

https://pond.imperialviolet.org/tech.html

Trevor