Minutes for UTA at IETF-96
minutes-96-uta-3

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?