-
Notifications
You must be signed in to change notification settings - Fork 43
OTF Report June and July 2018
The past couple of months have seen a significant amount of development and iteration on STARTTLS Everywhere.
MTA installer plugins for Certbot allows users to automatically set up their TLS configuration and automatically point it at the appropriate certificates being handled by Certbot.
- Developer alpha Postfix plugin landed in core Certbot repository, currently going through developer testing and bugfixes
- Drafting design document for allowing Certbot users to install the same certificate for multiple software (primarily for certificate renewal workflow)
- Help us test the plugin!
Collaborated closely with the Engineering & Design team at EFF to build an automated submission website for the policy list.
- The website is up and running.
- Currently working on bugfixes, improving documentation, and clearer/more robust error messaging.
Mail delivery may be impacted if a domain decides to migrate hosting providers or otherwise stops adhering to their policy. Such failures should be notified to the mail operator as soon as they occur, and operators should be able to request emergency removal from or updates to the list to minimize impact on mail delivery. However, this channel must be authenticated, so we will issue a DNS challenge to ensure the intent of an emergency policy change.
-
Client usage expectations document for reasonable turnaround on emergency responses.
- Users of the list are expected to update their list at least once every 24 hours for certain deliverability guarantees.
- Default mail-queuing time for most MTAs is several days, so deliverability is at-worst delayed.
- Following TLSRPT to eventually integrate a similar error-reporting mechanism for slow rollout (and to mitigate deliverability failures such as the above).
These are tools to generate configuration files from the policy list, that a particular MTA can consume and enforce rules for.
- Designed and implemented interface for implementing configuration generators.
- Ported Postfix configuration generator to new interface.
- List will be signed and updated every week, with new (validated) additions.
- Validation of mailserver policies occurs regularly, although it's partially manual (running several scripts to validate policies and update the list)
- Currently working through backlog of hundreds of submissions!
- Wrote a set of blogposts explaining existing problems with the email ecosystem, as well as what problems STARTTLS Everywhere is trying to solve: beginner-friendly blog post and more technical write-up.
- Talk at HOPE XII.
- Scheduled for tutorial/training talk as well as regular session talk at M3AAWG 44, in October.
In hindsight, these are some challenges we've faced and are planning on ironing out going forward.
- Insufficient prioritization. The project goals are extremely diverse, and not necessarily always directly aligned. There are several different valid avenues through which we could improve the email ecosystem, and this project tried to address several different of them at once. Eventually, we'd like to lower the difficulty barriers of setting up a secure mailserver with valid certificates, but we need to first prioritize securing SMTP over TLS (through some combination of promoting DNSSEC, or MTA-STS, or the STARTTLS policy pinning list).
- Manual list management combined with automated list submissoin. We should have automated list management before automating list submission; doing the opposite has caused significant delay and overhead in deploying secure and timely updates to the list.
- Lack of an existing secure update channel. Distributing HTTPS-pinning policy lists across the web is relatively easy since it can happen regularly through existing channels in clients like browser or web-ex updates. Something that may help would be to write something beyond this cronjob -- possibly a Linux daemon-- to act as the canonical or default update channel. The lack of an easy-to-install universal tool for secure list updates that MTA operators feel comfortable installing on their mailservers has made it difficult to deploy the list to clients. We originally considered doing it through a Certbot plugin such that updates happen next to automated renewals-- but we are reconsidering forcing MTAs to install Certbot in order to obtain the canonical update channel.
- Planning out secure update channel packaging and deployment.
- Following and integrating MTA-STS and TLSRPT drafts in some way.
- Ramping up development of MTA configuration tools for list support.
- Further automating list validation and submission process.
- Development of Certbot plugins for MTA software: Postfix beta launch, Dovecot alpha, and Sendmail alpha.
- Recruiting volunteers for further development help.