* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Uta Status Pages

Using TLS in Applications (Active WG)
Art Area: Adam Roach, Alexey Melnikov, Ben Campbell | 2013-Dec-11 —  
Chairs
 
 


IETF-100 uta minutes

Session 2017-11-15 1330-1500: Bras Basah - Audio stream - uta chatroom

Minutes

minutes-100-uta-00 minutes



          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.
          
          



Generated from PyHt script /wg/uta/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -