Minutes IETF100: uta
minutes-100-uta-00

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.