Subject: [hrpc] draft-ietf-uta-require-tls

From: Jim Fenton <[email-masked]>
Date: Mon, 23 Jul 2018 13:26:55 -0700

We ran out of time at last Thursday's hrpc meeting, so I'd like to point 
out some work that is going on in the uta (Using TLS for Applications) 
working group that may be of interest to this community.

I have been working on an SMTP extension called REQUIRETLS. One of the 
primary motivations for this extension is to secure email traffic 
against passive intermediaries and impostors. This would be valuable to 
users such as journalists, dissidents, and NGOs engaged in activities 
that might be considered sensitive in a given area.

The problem I have been trying to solve is that senders of email 
messages don’t have any control or knowledge whether their messages are 
sent via TLS transport once they have submitted them. STARTTLS for email 
is opportunistic: TLS transport is only used if the sender and receiver 
on a particular transit hop both support it and can agree on cipher 
suites, etc. Verification of the receiver (SMTP server) certificate is 
generally ignored, meaning that man-in-the-middle and other 
impersonation attacks are possible. And intermediaries can (and 
sometimes do) interfere in the negotiation of STARTTLS so that they can 
intercept the message traffic.

REQUIRETLS addresses this by allowing a message sender (SMTP client) to 
specify that all onward transmission of that message must be via TLS to 
a server with a verified certificate that also supports REQUIRETLS. Even 
if message bodies are end-to-end encrypted, TLS is still valuable in 
protecting the message header and other metadata from interception on 
the wire. The use of REQUIRETLS is also not visible to a passive 
attacker, because its use occurs within a TLS session.

There is a second aspect to REQUIRETLS where it can be used to loosen 
server-side TLS requirements (MTA-STS and DANE) in order to improve the 
delivery of important but non-sensitive traffic, but this is an entirely 
separate use case.

REQUIRETLS is described in an Internet Draft, 
draft-ietf-uta-require-tls, which is currently in working group last 
call. But there has been little support for REQUIRETLS from the 
communities that I think would find it valuable, and I’m looking for 
more support for development of implementations and for deployment of 
REQUIRETLS.  I'm hoping that hrpc folks (you) can help me find more. 
There are currently implementations for the Exim and the MDaemon mail 
servers, and I’d like to see more development as well.

Please let me know if you have any questions or suggestions, either 
directly, here, or on the uta mailing list.

-Jim

---

From: [email-masked]
Date: Tue, 24 Jul 2018 22:41:53 -0400

FWIW it makes sense to me.

I believe this is a link to the current draft:

  https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-require-tls/?include_text=1

On July 23, 2018 at 13:26 [email-masked] (Jim Fenton) wrote:
 > We ran out of time at last Thursday's hrpc meeting, so I'd like to point out
 > some work that is going on in the uta (Using TLS for Applications) working
 > group that may be of interest to this community.
 > 
 > I have been working on an SMTP extension called REQUIRETLS. One of the primary
 > motivations for this extension is to secure email traffic against passive
 > intermediaries and impostors. This would be valuable to users such as
 > journalists, dissidents, and NGOs engaged in activities that might be
 > considered sensitive in a given area.
 > 
 > The problem I have been trying to solve is that senders of email messages don’t
 > have any control or knowledge whether their messages are sent via TLS transport
 > once they have submitted them. STARTTLS for email is opportunistic: TLS
 > transport is only used if the sender and receiver on a particular transit hop
 > both support it and can agree on cipher suites, etc. Verification of the
 > receiver (SMTP server) certificate is generally ignored, meaning that
 > man-in-the-middle and other impersonation attacks are possible. And
 > intermediaries can (and sometimes do) interfere in the negotiation of STARTTLS
 > so that they can intercept the message traffic.
 > 
 > REQUIRETLS addresses this by allowing a message sender (SMTP client) to specify
 > that all onward transmission of that message must be via TLS to a server with a
 > verified certificate that also supports REQUIRETLS. Even if message bodies are
 > end-to-end encrypted, TLS is still valuable in protecting the message header
 > and other metadata from interception on the wire. The use of REQUIRETLS is also
 > not visible to a passive attacker, because its use occurs within a TLS session.
 > 
 > REQUIRETLS is described in an Internet Draft, draft-ietf-uta-require-tls, which
 > is currently in working group last call. But there has been little support for
 > REQUIRETLS from the communities that I think would find it valuable, and I’m
 > looking for more support for development of implementations and for deployment
 > of REQUIRETLS.  I'm hoping that hrpc folks (you) can help me find more. There
 > are currently implementations for the Exim and the MDaemon mail servers, and
 > I’d like to see more development as well.
 > 
 > Please let me know if you have any questions or suggestions, either directly,
 > here, or on the uta mailing list.
 > 
 > -Jim
 > 
 > 
 > _______________________________________________
 > hrpc mailing list
 > [email-masked]
 > https://www.irtf.org/mailman/listinfo/hrpc

-- 
        -Barry Shein

Software Tool & Die    | [email-masked]             | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 27 Jul 2018 12:33:17 +0200

Hi Jim,

>  > considered sensitive in a given area.

This makes a lot of sense.

>  > so that they can intercept the message traffic.
I think mail providers were afraid that let this hard-fail, right? Has
this changed?

>  > I’d like to see more development as well.

Are you looking for package maintainers, human rights relevant
deployments, funding, or researchers? I think we could help you with
contacts in all these fields, so a more specific ask would be
tremendously helpful!

Cheers,

Niels

-- 
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint	   2458 0B70 5C4A FD8A 9488
                   643A 0ED8 3F3A 468A C8B3

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 27 Jul 2018 07:15:46 -0400

After receiving considerable favourable feedback on this draft in
multiple venues, it is being evolved with a -01 version that includes
additional relevant international human rights instruments and provision
enumerations.  If anyone has suggestions along those lines, please let
me know.

The chief value propositions are the assembly in one place of all
relevant provisions that can be referenced with a tag, as well as a
greater awareness of the how instantiations of network based protocols,
architectures, and services and their operation affect human rights. 
There are ample contemporary examples, e.g.,
http://www.circleid.com/posts/20180702_trumps_tweets_flouting_the_cybercrime_treaty_curbs_on_racist/

best,
tony

---

From: Jim Fenton <[email-masked]>
Date: Sat, 28 Jul 2018 13:03:12 -0700

> I think mail providers were afraid that let this hard-fail, right? Has

For opportunistic TLS, ignoring certificate validation makes a lot of 
sense. Even an unauthenticated TLS connection provides protection 
against passive eavesdropping. It just doesn't protect against 
man-in-the-middle attacks. So it makes more sense to ignore certificate 
verification than to fail back to entirely unencrypted (unless you can't 
negotiate TLS at all).

REQUIRETLS removes the opportunistic nature from the transit, so it 
makes sense to enforce certificate verification when it is used.

> contacts in all these fields, so a more specific ask would be

Some of these:

- Package maintainers: Not yet, we need packages to maintain :)
- Human rights relevant deployments: This is the main thing that I was 
hoping for by reaching out to hrpc.
- Funding: Not needed for me, although some developers of 
implementations might be looking for some.
- Researchers: There was some good research done several years ago 
(http://dx.doi.org/10.1145/2815675.2815695 see especially section 5.1) 
and at some point it might be good to get some updated numbers. But not 
immediately a priority.

My main concern right now is that REQUIRETLS attract some notice and 
deployment so that it can so some good, rather than "merely" become a 
standards-track RFC.

-Jim