Meeting, UTA IETF 100 Agenda: https://datatracker.ietf.org/meeting/100/materials/agenda-100-uta/ - Agenda Bashing and Note Well - DEEP IESG status - MTA-STS open issues - REQUIRETLS update - Open Mic Leif: Most of our work is done. Emails. # MTA-STS. Presentation. https://datatracker.ietf.org/meeting/100/materials/slides-100-uta-mtasts/ Nicolas Lidzborski presenting. Jim Fenton: Sent in many comments; on STS Report, is there an attack envisioned for the l= attribute Nicolas: existing DKIM attack Jim: It may be operationally challenging; a bit of a layering violation. Also concerned about email as transport for sensitive information. There's sensitivity to the amount of traffic that flows between domains; require using TLS? People should pay attention to the endpoint to which reports are being sent. Alexey: probably another security consideration Leif: Leaning toward good to go without second WGLC Alexey: agree with the chair. Arnold @: Report meant to be used by whom? Nicolas: by receiving domain, e.g. for awareness if traffic is being downgraded # Require TLS, https://datatracker.ietf.org/meeting/100/materials/slides-100-uta-requiretls/ Jim Fenton presenting @1: RequireTLS=NO should be a header; take it all out of this draft and put it into a separate document Jim: it made the text of this draft more complicated. Nicolas: is there any concern with leaking what's happening during delivery? Jim: should only be negotiated under TLS Nicolas: a chain of mailservers, one of which is not supporting TLS? internal relaying in enterprise? Jim: I don't see that as sensitive. it's in received headers. Neil Jenkins: Recipient can ignore once it's in their internal network. Re options, good to align with MTA-STS can-specify Jim: started independently. Nicolas: if there's no guarantee, what's the value for the sender? Jim: there's no guarantee that message will be delivered; that host won't send a copy to Ft. Meade... Nicolas: direction. Are we asking recipients to protect end-to-end? Jim: if you advertise that you support REQUIRE-TLS, you're promising sender you'll respect that Arnold?: can you make that promise, when TLS terminates at one MTA and resumes. Consider legal intercept. Jim: we're protecting against intercepts other than MTAs in the path. This is not a substitute for end-to-end encryption. Some regimes where there are downgrade attacks. Reject the message and report to sender. You're denying others the opportunity for passive or downgrade attacks. DKG: Happy to see this going forward. Not every draft fixes every problem but this solves one usefully. Neil Jenkins:: agaist some threats, you probably shouldn't be using email. but this is a good way of reducing the required trusts Brian: +1 Your MTA can require someL Leif: spend more time on REQUIRETLS=no? Neil Jenkins: I find that one odd. Override MTA-STS (and possibly DANE)? Why do you need it? Jim: just one request for the feature. speculative Brian: I suggest pull it out, put it into a different draft. Leif: Can we be done by London? Jim: hoping for more input on options. How specific to allow requests to be? Neil: not lots of support for DANE< DNSSEC. Jim: we could add more specifics later Leif: Reviewers: DKG, Nicolas Lidzborski , Arnold Jim: implementors, please get in touch. # Open Mic Alexey: DEEP went to IESG eval; no pending DISCUSSes. One question on use of TLS SNI. EKR raised an issue re not much experience Leif: nearing the end of our pipeline. So far as we know, no one lining up for new work. Plan to close down after London. If you have something else, bring it quickly.