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?