IETF 96 / UTA WG / Tuesday, July 19, 2016 Summary: All agenda topics related to using TLS with e-mail protocols. Alexey replaced Stephen as the responsible AD. The discussion was highly technical and positive. Some of the main interested parties met for the first time f2f. There is a good chance that the next bulk of work can be done on the list and we may skip the next IETF. Outcome: MTA-MTA interface: both drafts have been updated before the IETF. More comments were received during the meeting. Main suggestions for improvement and are in the two areas (1) describing the state machine on both sides in more details and (2) adding considerations regarding protocols' parameters tuning (e.g., for HTTPS) suitable for different deployment cases. The authors will submit new revisions. MUA-MTA interface: the draft has been updated to bring it closer to the STS mechanism. Areas of possible synergy include registry and common in- band and out-of-band reporting mechanisms. The authors and Victor D. will continue iterate on those. The results will be reflected in future drafts' submissions. SMTP Require TLS: no updates to the draft. One suggestion: instead of Require - consider making "a list" of client commands; for example add "transmit with minimal latency without TLS". Meeting notes: Note well presented. D Margolis presented on SMTP MTA Strict Transport Security and TLS Reporting Described changes in the drafts since IETF 95 Described open issues Described current implementations B Leiba: add implementation list to the draft J Fenton: any implementation beyond publication of records? DM: Google likely to have send time validation this quarter V Dukhovni: Postfix probably no implementation until the spec is finalized. ID field needs multiple values so can do key rollover. State machine is underspecified per multiple MX. Needs clarification re DANE. D York: explain coexistence with DANE? DM: likely if you validate with DANE, you don't do STS or vice versa. Policy decision. VD: STS is a downgrade of DANE M Risher (remote): do attendees know of other implementations? there is an exim implementation in progress DM: would like open source for small sites and provide feedback VD: wants more specific details eg timeouts BL: if normal http usage doesn't match this use, could add more details re timeouts and such but don't do it if you don't need to T Hardie: deployment performance considerations are different in different situations, e.g. if you use http keepalive. Unlikely can come up with rules that work for everyone. VD: need more info on TLS failures J Levine: mail reporting is underspecified, is report in body, attachment? Also need way to permit report to third parties O Levin (chair) /DM: need to add more specificity or tuning parameters. Clarify state machine. OL: understand what to do now? DM: yes C Newman: upcoming tasks to align STS MTA implementations D York: this assumes TOFU? DM: Yes. DY: put that in security considerations DM: could ship MTA with preloaded policies perhaps DY: DNSSEC helps here VD: public key pinning and cert transparency don't work here attackers can spam CT logs with gibberish. CAs would have to sign policies, which is unlikely. key pinning defeated by injecting a fake MX that matches STS name pattern, also works poorly when there are lots of MTAs C Newman presented DEEP, now STS for MUAs described changes since last time, largely to align with STS design goal is to align as far as possible to minimize complexity use json syntax or key-value? DM: how many directives are shared? CN: maxage, dunno if more DM: why shared registry if so few shared? CN: one registry is easier to manage than two D Crocker: need sense that these are reasonable to keep together S Leonard (remote):as a parser writer, i say reuse is good. and for security, reusing constructs that have already been analyzed, should lead to fewer implementation errors. CN: shared reporting mechanism? suggest sharing out of band reporting VD: offers to co-edit in-band reporting mechanism CN: looking for guidance on whether to share directive syntax OL: ask on list to see who's implemented draft CN: assume not sharing syntax S Farrell: will switch AD responsibility for this group with Alexey D Fenton presented on SMTP require TLS one MTA planning to implement it VD: add more detailed requirements? add anti-tls option for mail that's time sensitive but not private? OJ: this failed in SIP, multihop stuff can't force later hops to do it BL: this assumes good behavior OL: AOB?