O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

REQUIRETLS: Sender Control of TLS Requirements

332 visualizações

Publicada em

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.

Publicada em: Internet
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

REQUIRETLS: Sender Control of TLS Requirements

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 11. The TLS-Required header field And now for something completely different…
  12. 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. 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. 14. Questions?

×