Recent policy mechanisms (notably MTA-STS and DANE) allow email recipient domains to advertise their support for TLS email transport. REQUIRETLS (RFC 8689) complements those mechanisms by giving message senders the ability to send messages with the requirement that they be transported over TLS -- or not at all. This talk describes the REQUIRETLS protocol extensions as well as potential mechanisms to allow users to control the selection of the REQUIRETLS mechanisms for relevant messages.

1. M3AAWG 48th General Meeting | San Francisco, CA | February 2020
REQUIRETLS: Sender Control of TLS Requirements
Jim Fenton
18 February 2020
San Francisco, CA

2. M3AAWG 48th General Meeting | San Francisco, CA | February 2020
What is REQUIRETLS?
• An option to require TLS transport of a given mail message
• Applied by (or close to) the sender
• RFC 8689, issued in November 2019
• Little implementation to date
– Prototypes developed for Exim and MDaemon

3. M3AAWG 48th General Meeting | San Francisco, CA | February 2020
Why REQUIRETLS?
• Email transport encryption is opportunistic
– If STARTTLS can’t be negotiated, messages sent in the clear
– If certificates don’t verify, that’s usually ignored
– This is done silently, without awareness of sender
• End-to-end content encryption isn’t enough
– Message headers aren’t included
– Headers contain important metadata
• Addresses of correspondents
• Message subject line
• Links to previous messages

4. M3AAWG 48th General Meeting | San Francisco, CA | February 2020
Why REQUIRETLS?
• Some middleboxes actively interfere with STARTTLS negotiation
– Enterprises and ISPs [1] wanting to monitor outgoing traffic
– Some countries [2] [3] that want to monitor email traffic on a
national basis
[1] Hoffman-Andrews, Jacob. 2014. “ISPs Removing Their Customers’ Email Encryption.” Electronic Frontier
Foundation. November 11, 2014. https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks.
[2] Durumeric, Zakir, David Adrian, Ariana Mirian, James Kasten, Elie Bursztein, Nicolas Lidzborski, Kurt Thomas,
Vijay Eranti, Michael Bailey, and J. Alex Halderman. 2015. “Neither Snow Nor Rain Nor MITM...: An Empirical
Analysis of Email Delivery Security.” In Proceedings of the 2015 Internet Measurement Conference, 27–39. IMC
’15. Tokyo, Japan: Association for Computing Machinery. https://doi.org/10.1145/2815675.2815695.
[3] “Who’s That Knocking At My Door? Understanding Surveillance In Thailand.” n.d. Privacy International. Accessed
February 10, 2020. http://privacyinternational.org/report/61/whos-knocking-my-door-understanding-surveillance-
thailand.

5. M3AAWG 48th General Meeting | San Francisco, CA | February 2020
REQUIRETLS use cases
• Journalists, dissidents, and other NGOs in semi-hostile regimes
• Messages where metadata (e.g., correspondent addresses) should
be protected from disclosure
• Analogous to “Encrypt for Transmission Only” used by DoD
– Sensitive but unclassified
• Objective: make monitoring transparent and consensual
– Not to defeat monitoring required for compliance purposes

6. M3AAWG 48th General Meeting | San Francisco, CA | February 2020
REQUIRETLS operation
• Messages tagged REQUIRETLS can only be sent when:
– Server MTA has been authenticated (DNSSEC or MTA-STS)
– STARTTLS has been negotiated with valid certificate
• DANE or trust chain
– Server advertises REQUIRETLS support
• Messages are bounced otherwise

7. M3AAWG 48th General Meeting | San Francisco, CA | February 2020
How to use REQUIRETLS
• Senders requiring TLS transport tag their messages in the SMTP
transaction
– Look up and authenticate server MTA name (MX)
– Negotiate STARTTLS
– Verify server certificate matches MTA name
– In second EHLO, ensure that server advertises REQUIRETLS
– Include REQUIRETLS option in MAIL FROM:
MAIL FROM <roger@example.org> REQUIRETLS
– Bounce message if any of these fail

8. M3AAWG 48th General Meeting | San Francisco, CA | February 2020
Deciding to use REQUIRETLS
• REQUIRETLS trades off deliverability for security
– Not suitable for all messages
– Probably should be decided by the sender
• REQUIRETLS could be selected for individual messages by:
– Explicit user action (e.g., button on UI)
– Ruleset on MUA (by domain, address, subject…)
– Ruleset on submission MTA (by user or global)

9. M3AAWG 48th General Meeting | San Francisco, CA | February 2020
REQUIRETLS and “bounce” messages
• Bounce messages are generated when REQUIRETLS can’t relay
• But bounce messages:
– Contain a lot of interesting metadata
– May not have REQUIRETLS support
• Handling:
– Include REQUIRETLS on bounce
– Force inclusion of only headers in bounce (RET=HDRS)
– But if MAIL FROM is empty, do not discard bounce because of
REQUIRETLS
– Warn users about possible leakage

10. M3AAWG 48th General Meeting | San Francisco, CA | February 2020
Threats to opportunistic TLS
Threat
• Interference with
negotiation
• Invalid server certificate
• Bogus/spoofed MX
record
• MTA trust
Mitigation
• Refuse to send message
unless TLS negotiated
• Refuse to send message
• Require DNSSEC or
MTA-STS for recipient
domain
• Assumed trustworthy

11. The TLS-Required header field
And now for something completely different…

12. M3AAWG 48th General Meeting | San Francisco, CA | February 2020
Allowing message transmission with
policy failure
• DANE and MTA-STS advertise recipient domain support of
STARTTLS
– “Don’t send a message to me without STARTTLS”
• What if sender really doesn’t care if the message goes in the clear?
– Telling a domain that their certificates have expired
• RFC 8689 has a second mechanism to handle this
– Header field TLS-Required: No
– Explicitly prioritizes delivery over domain policy

13. M3AAWG 48th General Meeting | San Francisco, CA | February 2020
TLS-Required caveats
• Doesn’t help if receiving MTA refuses to accept messages without
STARTTLS
• No way to determine if relaying MTAs support this feature
– Insisting on MTA support would be counter-productive to
delivery
• Best-effort feature

14. Questions?